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
[email protected]
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
