[webkit-dev] parallel rendering in WebKit

Zoltan Herczeg zherczeg at inf.u-szeged.hu
Sat Feb 20 03:22:02 PST 2010


thanks for all of your for your help.

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

We plan to do the painting on a background image. When all the painting
finished, the image appears on the screen. We don't need to duplicate the
dom tree, only the painting commands should be sent to the thread. We
could keep the changes below RenderContext level in this way.

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

No need thread safe refcounting, since when a request object is processed
by the thread, the thread sends back the request object to the main
thread, which can release the resources. It is necessary, since memory
alloc / free pairs on a memory chunk must be executed by the same thread.
We can post a series of commands to the thread message queues (including
the main thread), which will processed later (no wait is necessary).

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

Not anymore. The UI design of mobile or handheld devices use more and more
html-based content. It is easier for both UI designers (enough to know how
to create html pages) and developers (a browser is needed anyway, and not
need to maintain a separate UI rendering engine). Of course we need
reliable and fast brower engines to achive these features.

I can't promise any major gain at this momment, but it seems there is not
any design issue in WebKit, which makes this approach impossible. Wish us
luck :)


More information about the webkit-dev mailing list