Re: [webkit-dev] parallel painting
On Mon, 2011-06-06 at 17:59 +0530, Monil Parmar wrote: How to use it for gtk launcher...I think it is for safari. A bit late for this answer, but for completeness sake: GtkLauncher is not a full browser, so it doesn't expose many features available in WebKitGTK+. You should use Epiphany or Midori preferably for trying these things. In any of these browsers you can get to the inspector by right-clicking anywhere on the page and selecting 'Inspect Element'. Cheers, -- Gustavo Noronha Silva g...@gnome.org GNOME Project ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] parallel 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 e...@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 zherc...@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. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] parallel painting
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 e...@webkit.org mailto:e...@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 zherc...@inf.u-szeged.hu mailto:zherc...@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 ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] parallel painting
Is there any way to find out how much time is taken in parsing, layout,rendering, style resolution or java script execution, while loading a webpage. monpar wrote: Is there any way to find out how much time is taken in parsing, layout,rendering, style resolution or java script execution, while loading a webpage. Eric Seidel-6 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 zherc...@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 -- View this message in context: http://old.nabble.com/parallel-painting-tp28131184p31782203.html Sent from the Webkit mailing list archive at Nabble.com. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] parallel painting
Yes. Use the Timeline panel in WebKit Inspector: http://www.webkit.org/blog/1091/more-web-inspector-updates/#timeline_panel On Mon, Jun 6, 2011 at 14:44, monpar monil.par...@gmail.com wrote: Is there any way to find out how much time is taken in parsing, layout,rendering, style resolution or java script execution, while loading a webpage. monpar wrote: Is there any way to find out how much time is taken in parsing, layout,rendering, style resolution or java script execution, while loading a webpage. Eric Seidel-6 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 zherc...@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 -- View this message in context: http://old.nabble.com/parallel-painting-tp28131184p31782203.html Sent from the Webkit mailing list archive at Nabble.com. ___ 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
Re: [webkit-dev] parallel painting
How to use it for gtk launcher...I think it is for safari. On Mon, Jun 6, 2011 at 4:39 PM, Mikhail Naganov mnaga...@chromium.orgwrote: Yes. Use the Timeline panel in WebKit Inspector: http://www.webkit.org/blog/1091/more-web-inspector-updates/#timeline_panel On Mon, Jun 6, 2011 at 14:44, monpar monil.par...@gmail.com wrote: Is there any way to find out how much time is taken in parsing, layout,rendering, style resolution or java script execution, while loading a webpage. monpar wrote: Is there any way to find out how much time is taken in parsing, layout,rendering, style resolution or java script execution, while loading a webpage. Eric Seidel-6 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 zherc...@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 -- View this message in context: http://old.nabble.com/parallel-painting-tp28131184p31782203.html Sent from the Webkit mailing list archive at Nabble.com. ___ 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
Re: [webkit-dev] parallel painting
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 zherc...@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: barbi...@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
Re: [webkit-dev] parallel painting
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 zherc...@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
Re: [webkit-dev] parallel painting
Date: Mon, 5 Apr 2010 17:54:35 -0800 From: barbi...@profusion.mobi To: zherc...@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: barbi...@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:WL:en-US:WM_HMP:042010_2 ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] parallel painting
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 zherc...@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
Re: [webkit-dev] parallel painting
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? ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] parallel painting
On Sat, Apr 3, 2010 at 9:32 PM, Zoltan Herczeg zherc...@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: barbi...@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
[webkit-dev] parallel painting
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
