[webkit-dev] parallel rendering in WebKit

[Maciej Stachowiak]

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