Hi, I am working on a parallel painting feature for WebKit (bug id: 36883). Basically it records the painting commands on the main thread, and replay them on a painting thread. The gain would be that the recording operation is cheap. Currently it is Qt specific, but I could make it more platform independent if other ports are interested. Zoltan
I think we'd be interested to see a cross-platform version from the perspective of the OpenVG graphics backend. On Sunday 04 April 2010 01:32:54 am Zoltan Herczeg wrote:
Hi,
I am working on a parallel painting feature for WebKit (bug id: 36883). Basically it records the painting commands on the main thread, and replay them on a painting thread. The gain would be that the recording operation is cheap. Currently it is Qt specific, but I could make it more platform independent if other ports are interested.
Zoltan
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
On Sat, Apr 3, 2010 at 9:32 PM, Zoltan Herczeg <zherczeg@inf.u-szeged.hu> wrote:
Hi,
I am working on a parallel painting feature for WebKit (bug id: 36883). Basically it records the painting commands on the main thread, and replay them on a painting thread. The gain would be that the recording operation is cheap. Currently it is Qt specific, but I could make it more platform independent if other ports are interested.
EFL port would be interested in this. Could you provide more details on the implementation? Is the painting thread a single thread, or is it being split to N cores? Did you consider the alternative that is isolate webkit layout in another thread as well? From our environment tests (embedded systems), re-layout process can take few seconds without any paint... that being done in the main thread hurts the whole experience as the event processing of menus, animations and others are blocked. In an ideal world WebKit would never block, it would just proxy input and output events to its thread (hard, error-prone... :-/), there it would layout, render and when ready release the main thread to use the painted contents (maybe tiles as the Qt port now enables). BR, -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -------------------------------------- MSN: barbieri@gmail.com Skype: gsbarbieri Mobile: +55 (19) 9225-2202
Hi, Thank all of you for your feedbacks! Let's continue this discussion in the bug report, I will provide more details there. Zoltan
On Sat, Apr 3, 2010 at 9:32 PM, Zoltan Herczeg <zherczeg@inf.u-szeged.hu> wrote:
Hi,
I am working on a parallel painting feature for WebKit (bug id: 36883). Basically it records the painting commands on the main thread, and replay them on a painting thread. The gain would be that the recording operation is cheap. Currently it is Qt specific, but I could make it more platform independent if other ports are interested.
EFL port would be interested in this. Could you provide more details on the implementation? Is the painting thread a single thread, or is it being split to N cores?
Did you consider the alternative that is isolate webkit layout in another thread as well? From our environment tests (embedded systems), re-layout process can take few seconds without any paint... that being done in the main thread hurts the whole experience as the event processing of menus, animations and others are blocked. In an ideal world WebKit would never block, it would just proxy input and output events to its thread (hard, error-prone... :-/), there it would layout, render and when ready release the main thread to use the painted contents (maybe tiles as the Qt port now enables).
BR,
-- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -------------------------------------- MSN: barbieri@gmail.com Skype: gsbarbieri Mobile: +55 (19) 9225-2202
----------------------------------------
Date: Mon, 5 Apr 2010 17:54:35 -0800 From: barbieri@profusion.mobi To: zherczeg@inf.u-szeged.hu CC: webkit-dev@lists.webkit.org Subject: Re: [webkit-dev] parallel painting
On Sat, Apr 3, 2010 at 9:32 PM, Zoltan Herczeg wrote:
Hi,
I am working on a parallel painting feature for WebKit (bug id: 36883). Basically it records the painting commands on the main thread, and replay them on a painting thread. The gain would be that the recording operation is cheap. Currently it is Qt specific, but I could make it more platform independent if other ports are interested.
EFL port would be interested in this. Could you provide more details on the implementation? Is the painting thread a single thread, or is it being split to N cores?
Did you consider the alternative that is isolate webkit layout in another thread as well? From our environment tests (embedded systems), re-layout process can take few seconds without any paint... that being done in the main thread hurts the whole experience as the event processing of menus, animations and others are blocked. In an ideal world WebKit would never block, it would just proxy input and output
What prevents this right now? That is, what puts work on an event thread instead of launching a worker thread? Generally of course event threads handle and record events- set flags, manage workers, maybe do simple things with existing data but no IO or unpredictable operations that may encounter contention( block). Certainly you don't want to use it to execute things that may require user intervention. I guess besides watching the disk light blink for "VM" while I'm trying to do something simple, I've personally found little more that is annoying than an unresponsive GUI thread. From the developer standpoint, you are stuck with options for responding to exceptional or pathological conditions with, say webpages or network conditions, if you can't count on a responsive GUI thread to process user input. I guess on limited resource devices threads are limited and launching new threads does create problems, often slowing things down overall when parallelism is the intent, but in this case you are only trying to preserve one thread's response time. Indeed, on phone's the first rule has been "don't hang the UI thread" since this allows user to report bugs and have a live menu system for recovery from wierd conditions.
events to its thread (hard, error-prone... :-/), there it would layout, render and when ready release the main thread to use the painted contents (maybe tiles as the Qt port now enables).
BR,
-- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -------------------------------------- MSN: barbieri@gmail.com Skype: gsbarbieri Mobile: +55 (19) 9225-2202 _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
_________________________________________________________________ Hotmail is redefining busy with tools for the New Busy. Get more from your inbox. http://www.windowslive.com/campaign/thenewbusy?ocid=PID28326::T:WLMTAGL:ON:W...
Parallel painting would only be useful if the graphics layer is incredibly slow. In most WebKit ports we do not see very much time painting, rather time is more often spent in layout, style resolution, or javascript execution/bindings. -eric On Sat, Apr 3, 2010 at 10:32 PM, Zoltan Herczeg <zherczeg@inf.u-szeged.hu> wrote:
Hi,
I am working on a parallel painting feature for WebKit (bug id: 36883). Basically it records the painting commands on the main thread, and replay them on a painting thread. The gain would be that the recording operation is cheap. Currently it is Qt specific, but I could make it more platform independent if other ports are interested.
Zoltan
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Of course, I did a lot of profiling before (using oprofile), and painting was slow on my platform. Zoltan
Parallel painting would only be useful if the graphics layer is incredibly slow. In most WebKit ports we do not see very much time painting, rather time is more often spent in layout, style resolution, or javascript execution/bindings.
-eric
On Sat, Apr 3, 2010 at 10:32 PM, Zoltan Herczeg <zherczeg@inf.u-szeged.hu> wrote:
Hi,
I am working on a parallel painting feature for WebKit (bug id: 36883). Basically it records the painting commands on the main thread, and replay them on a painting thread. The gain would be that the recording operation is cheap. Currently it is Qt specific, but I could make it more platform independent if other ports are interested.
Zoltan
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
On Tuesday 06 April 2010 13:42:30 Zoltan Herczeg wrote:
Of course, I did a lot of profiling before (using oprofile), and painting was slow on my platform.
Can you use oparchive to make the profile available? Also when you say painting? Do you mean function (inclusive) spend below QWebFrame::render? or really the work on QPainter and the RenderTree doing the painting?
(Resending from correct email) For HTML5 canvas animations, painting speed is very significant. Android uses a retain mode rendering approach as well; where paint operations are recorded on a WebCore thread and painting is actually done on the UI thread. It isn't necessarily the best approach. But I suppose it depends the platform whether or not there is much to gain. You still need to worry about synchronization. On 6 April 2010 03:24, Eric Seidel <eric@webkit.org> wrote:
Parallel painting would only be useful if the graphics layer is incredibly slow. In most WebKit ports we do not see very much time painting, rather time is more often spent in layout, style resolution, or javascript execution/bindings.
-eric
On Sat, Apr 3, 2010 at 10:32 PM, Zoltan Herczeg <zherczeg@inf.u-szeged.hu> wrote:
Hi,
I am working on a parallel painting feature for WebKit (bug id: 36883). Basically it records the painting commands on the main thread, and replay them on a painting thread. The gain would be that the recording operation is cheap. Currently it is Qt specific, but I could make it more platform independent if other ports are interested.
Zoltan
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
-- Pierre.
On 6/9/2011 8:24 PM, Pierre-Antoine LaFayette wrote:
Android uses a retain mode rendering approach as well; where paint operations are recorded on a WebCore thread and painting is actually done on the UI thread. It isn't necessarily the best approach. But I suppose it depends the platform whether or not there is much to gain. You still need to worry about synchronization.
...
On 6 April 2010 03:24, Eric Seidel <eric@webkit.org <mailto:eric@webkit.org>> wrote:
Parallel painting would only be useful if the graphics layer is incredibly slow. In most WebKit ports we do not see very much time
...
On Sat, Apr 3, 2010 at 10:32 PM, Zoltan Herczeg <zherczeg@inf.u-szeged.hu <mailto:zherczeg@inf.u-szeged.hu>> wrote: > Hi, > > I am working on a parallel painting feature for WebKit (bug id: 36883). > Basically it records the painting commands on the main thread, and replay > them on a painting thread. The gain would be that the recording operation
Is this something that could be used to "duplicate" painting commands? I'm very interested in enabling secondary painting contexts, to enable better representation of Zoom, and other common assistive techniques. Example: If the recording is used, prefixed with scale and crop, a user could be presented with a crisp and clear magnification of a focused region or other sub-region. Such techniques could also be useful for remote viewing, via serialization, and for efficient screen dumps [assuming the render works, of course]. It'd be great, if some time, secondary user agents, like the popular ZoomText Magnifier, were able to interact with WebKit and request regions to be painted at a higher resolution, so as to display the magnified image at native resolution. Does that make sense? Is that something that this technique might eventually provide? I suspect that screen mirroring and other forms of screen sharing will become more common in use, as more and more physical screens become common in our common lives. -Charles
Hi, wow, your use case is really interesting. I have never thought about that. Yeah, that would be a simple extension to the parallel painting system, you could replay the commands anywhere, any times. It is basically a vector graphics representation of the screen, you could scale it up. Actually I am really happy that those techinques we were working on eventually attracting others. We were the first one who played with parallelization, SIMD instruction sets, and their usage is growing in WebKit now. Devices (people) actually use them! It seems playing with new approaches (even radical changes) are never a waste of time. We could learn a lot from them. Regards, Zoltan
On 6/9/2011 8:24 PM, Pierre-Antoine LaFayette wrote:
Android uses a retain mode rendering approach as well; where paint operations are recorded on a WebCore thread and painting is actually done on the UI thread. It isn't necessarily the best approach. But I suppose it depends the platform whether or not there is much to gain. You still need to worry about synchronization.
...
On 6 April 2010 03:24, Eric Seidel <eric@webkit.org <mailto:eric@webkit.org>> wrote:
Parallel painting would only be useful if the graphics layer is incredibly slow. In most WebKit ports we do not see very much time
...
On Sat, Apr 3, 2010 at 10:32 PM, Zoltan Herczeg <zherczeg@inf.u-szeged.hu <mailto:zherczeg@inf.u-szeged.hu>> wrote: > Hi, > > I am working on a parallel painting feature for WebKit (bug id: 36883). > Basically it records the painting commands on the main thread, and replay > them on a painting thread. The gain would be that the recording operation
Is this something that could be used to "duplicate" painting commands?
I'm very interested in enabling secondary painting contexts, to enable better representation of Zoom, and other common assistive techniques.
Example: If the recording is used, prefixed with scale and crop, a user could be presented with a crisp and clear magnification of a focused region or other sub-region.
Such techniques could also be useful for remote viewing, via serialization, and for efficient screen dumps [assuming the render works, of course].
It'd be great, if some time, secondary user agents, like the popular ZoomText Magnifier, were able to interact with WebKit and request regions to be painted at a higher resolution, so as to display the magnified image at native resolution.
Does that make sense? Is that something that this technique might eventually provide?
I suspect that screen mirroring and other forms of screen sharing will become more common in use, as more and more physical screens become common in our common lives.
-Charles
participants (8)
-
Adam Treat
-
Charles Pritchard
-
Eric Seidel
-
Gustavo Sverzut Barbieri
-
Holger Freyther
-
Mike Marchywka
-
Pierre-Antoine LaFayette
-
Zoltan Herczeg