[Webkit-unassigned] [Bug 100341] [META][GTK] Implement threaded model of Coordinated Graphics

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=100341





--- Comment #2 from Noam Rosenthal <noam at webkit.org>  2012-11-16 07:42:57 PST ---
> Any comments/concerns are appreciated.

OK, some comments/concerns :)
First of all you guys are doing an astounding job with this, and I'm happy with any progress re. coordinated graphics,  so don't get my architectural ideas as criticism...

1. GTK would run into the same problem we ran with with Qt when running this on embedded systems. With the "threading on the web process" approach, you still have to pass via a compositing step (e.g. XComposite on GLX) for every frame in a CSS animation. For desktop this is fine, for some platforms you'd find that the performance is unacceptable and the animations lag behind. We went through the trouble of writing IPC coordinated graphics because of this.

2. The optimizations we have in place today for fixed positioned elements and later for overflow-scroll would not work with the threaded model.

3. I think WebKit2 is the wrong place for this. If you really want to go down this route, I'd prefer it if we made TExtureMapper into more of a transaction/actor model, and make it threadable (it's already pretty thread safe), rather than trying to put threading code in WebKit2.

It feels a little bit hacky to put something like LayerTreeCoordinatorClientThreaded.h inside WebProcess/WebPage/CoordinatedGraphics; Feels like all of this belongs in WebCore/.../texmap, and  then we can make the IPC version work as a client that is implemented inside WebKit2. Also I don't see why this should not work on WebKit1. 
It feels like some of the architectural decisions are based on convenience of using existing code, but don't take the whole picture unto account :)

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.