[webkit-dev] parallel rendering in WebKit

[Leo Meyerovich]

We've been experimenting in our model with various modes of parallel 2D 
rendering (basic theme: GPU/SMP support rocks) but have a more wide open 
design space than WebKit's.

For a not-too-painful approach, looks like Firefox is doing well, and 
that's even for D2D (not retained mode): check out the last few posts @ 
http://www.basschouten.com/ .  Flash does a bunch as well, but that's 
less obviously transferred.

Parallelism can be used at multiple levels within the renderer -- SIMD, 
threads, and/or GPU -- I was actually under the impression that WebKit 
on the iPhone already uses hardware acceleration for painting. For the 
latter case, the hardware was made for pushing pixels, so the 
performance question should be of how much of a speedup, not whether 
there is one.

- Leo

[[ A little further out, I've been going over the CSS spec, and found 
that a lot of the CSS transform stuff maps nicely into OpenGL as it 
doesn't impact layout; structured extensions like adding shaders to CSS 
surfaces doesn't sound too crazy at this point. This seems well-beyond 
the scope of this list, however. ]]



Maciej Stachowiak wrote:
>
> On Feb 19, 2010, at 2:36 PM, Zoltan Herczeg wrote:
>
>> Hi,
>>
>> as all of you probably know, smp based systems are getting widespread 
>> even
>> in the embedded domain, and we hope we can speed up webkit on these
>> systems. We did some profiling, and seemed the platform dependent
>> rendering took 50% of the total runtime (at least on our test 
>> platforms).
>> We are thinking about adding some parallel rendering support for WebKit,
>> probably mostly platform dependent code, but the threading support could
>> be reused by different ports.
>>
>> The plan is opening a rendering thread for each document object. This
>> thread is dedicated to rendering, the resource management is still 
>> done by
>> the main thread. In other words, functions like drawRect (in
>> GraphicsContext.h) creates a small object, which contains the 
>> arguments of
>> the called function, and passing this object to the thread. The thread
>> would do the painting, and send back the object after it is 
>> processed. The
>> main thread can free the memory space of the object later, and 
>> dereference
>> the resources (we hope resources like fonts and images are not need 
>> to be
>> duplicated).
>>
>> This is still a vague idea, and we are still investigating the
>> possibilities. What is your opinion? Do you know about any major 
>> blockers
>> we should know about?
>
> I would be worried about correctness - if painting is not complete by 
> the time the paint method returns, then you could get flashes of 
> intermediate states showing up onscreen.
>
> I suspect resources like fonts or images *will* need to be duplicated, 
> either that or use thread-safe refcounting and copy-on-write. The 
> internal state of images can be mutated by progress in loading the 
> image, or by ongoing animation.
>
> I'm also curious how this will help overall rendering time. Embedded 
> platforms would normally only be displaying one document at a time, so 
> how will one thread per document help?
>
> Regards,
> Maciej
>
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev