----------------------------------------
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...