[Webkit-unassigned] [Bug 102994] [META][Qt] Implement Threaded Coordinated Graphics in WebKit1

[bugzilla-daemon at webkit.org]

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





--- Comment #12 from Jocelyn Turcotte <jocelyn.turcotte at digia.com>  2013-01-02 04:32:28 PST ---
(In reply to comment #9)
> I think later maybe we can do something like paint in the main thread to a QPaintBuffer / cairo_recording_surface, and do the actual painting to the buffer in the compositor thread.
> But I agree that right now in the Qt context we don't really offload too much to the compositor thread. also I'm not sure if in order to achieve this background painting we have to put 

Can you explain what is the ultimate goal regarding what will be offloaded to the secondary thread? This is still not clear.

>From my understanding, the reason that Chrome has a compositor thread is because they have set the dependency in this order, fastest to slowest:
1) The user-visible widget/window and the GPU process. This is the one needing maximal responsiveness.
2) The web process compositor thread. Gets scroll events before the main thread does to allow recompositing even if the main thread is busy and sends the resulting FBO to (1)
3) The web process main thread. This is the slow one, the source of latency that we want to make sure won't block (1)

See http://www.chromium.org/developers/design-documents/compositor-thread-architecture

This is what we have with Qt5/WK2:
a) The QtQuick rendering thread. We are currently doing the above's (1) regarding rendering, plus (2) since we didn't want to create an extra shared GL context to render the FBO. The delegatesScrolling() logic allows us to scroll the main layer without having to go through (c).
b) The Qt application's main thread.
c) The WK2 web process. Same as (3) above.

This is how I see where we are trying to head for WK1 with this design:
y) The main application thread. Does the above (1) and (3)
z) The AC thread. Does the above (2)

Now this is what doesn't make sense to me, why would we try to offload AC to a secondary thread while our main thread, also responsible for the final rendering to the user, is already depending on the highest sources of latency in the architecture: loading, script execution and layouting?
Even if the AC thread is free as the wind to render the composited FBO, this speed won't have any advantage since we will have to wait until the main thread is ready before the FBO can be shown to the user. Same for scrolling events, they won't be able to make it to the AC thread efficiently since they have to go through the slowest entity first.
The only advantage I see of all of this regarding performance is that we will be able to compute a few matrix operations in parallel, but I'm not even sure if this will be enough to par with the thread overhead.

The initial need of GTK in bug #100341 was about WK2, why is WK1 having anything to do with this?

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