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