[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 #3 from Huang Dongsung <luxtella at company100.net>  2012-11-18 21:50:31 PST ---
(In reply to comment #2)
> 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...

Thank for your valuable feedback. Your concern is very reasonable. I’ll explain why we refactored Coordinated Graphics instead of GrahpicsLayerTextureMapper.

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

We separated your first concern into two questions:
1. Does the "threading on the web process" approach cause an additional compositing step?
2. Is threaded coordinated graphics unacceptable because of unpredictable performance of sharing a surface between processes (e.g. XComposite)?

The answer to the first question is “no” in GTK+. GTK+ main loop in UI Process needs to composite the result of TexMap and other UI toolkits, as QSGNode did. So we always need an additional compositing step for every frame, regardless of using IPC coordinated graphics or Threaded coordinated graphics.

I’ll describe our opinion for the second question. If GTK+ uses IPC coordinated graphics, we would use some cairo way to share a texture between threads so that the main thread composites the result that painting thread painted.
If GTK+ uses Threaded coordinated graphics, we need platform specific ways, something like XComposite, to share a surface between processes. I agree on your opinion that the performance of XComposite is unpredictable on some platforms. However, each platform has a cross process surface sharing mechanism for windows compositor and, IMHO, Threaded coordinated graphics can have similar performance to IPC coordinated graphics if we choose a proper surface sharing mechanism on the platform (e.g. EGLImage). How about your opinion, mrobinson and noam?

p.s. You said the performance was unacceptable on embedded platforms. Could you explain in more detail? For example, which device or platform did you try on? Did you use XComposite or EGLImage?

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

I cannot fully understand how threaded coordinated graphics cannot satisfy some requirements that IPC coordinated graphics satisfies. Both implementations are very similar except for the message passing mechanism. Could you explain in more detail?

> 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 :)

Making a threaded version of GraphicsLayerTextureMapper is also a good idea. I agree that TextureMapperLayer is already pretty thread safe. However, if we focus on changing GraphicsLayerTextureMapper, we need to make new classes like GraphicsLayerThreadedTextureMapper, because we have to change GraphicsLayerTextureMapper a lot, and other clients (e.g. coordinated graphics) would not want GraphicsLayerTextureMapper to becomes complex. 

We thought GraphicsLayerThreadedTextureMapper will be very similar to CoordinatedGraphicsLayer after we add all features for threading. For example, if we use TiledBackingStore in GraphicsLayerThreadedTextureMapper to share backing store, GraphicsLayerThreadedTextureMapper will be similar to CoordinatedGraphicsLayer. Threaded model also need the class that plays a similar role to LayerTreeCoordinator, as chromium compositor has CCLayerTreeHost.
So, we thought reusing is better than reinventing wheel.

I absolutely agree that this can also work on WebKit1. Our next step is to make WebKit1 use Threaded coordinated graphics. We will need to move shareable code from WebKit2/coordinatedgraphics to platform/graphics/texmap/coordinatedgraphics to reuse them in WebKit1.

Moreover, I think reusing coordinated graphics is more convenient for maintaining. For example, if we have another threaded model implementation, alex who made coordinated graphics cache custom filter programs would have to change the threaded model implementation too.

I want to listen to your opinion. :)

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