[webkit-dev] parallel painting

[Mike Marchywka]

----------------------------------------
> Date: Mon, 5 Apr 2010 17:54:35 -0800
> From: barbieri at profusion.mobi
> To: zherczeg at inf.u-szeged.hu
> CC: webkit-dev at 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 at gmail.com
> Skype: gsbarbieri
> Mobile: +55 (19) 9225-2202
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at 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