[Webkit-unassigned] [Bug 69048] Separate compositor platform support from webkit's platform support

[bugzilla-daemon at webkit.org]

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





--- Comment #19 from Antoine Labour <piman at chromium.org>  2011-10-06 19:09:49 PST ---
(In reply to comment #18)
> (From update of attachment 110074 [details])
> View in context: https://bugs.webkit.org/attachment.cgi?id=110074&action=review
> 
> I think a lot of our threading stuff will explode if the compositor's notion of the "main thread" and the "compositor thread" are actually the same thing - we do blocking calls from one to the other.

I know it's confusing... there's possibly up to 3 threads involved:
(1) the webkit main thread
(2) the compositor client thread
(3) the compositor thread.

This patch makes it possible to have (1) != (2). In the renderer, nothing changes, and (1) == (2), but in the browser process we instantiate webkit on a background thread, but we need to call the compositor from the UI thread.
This patch doesn't change anything wrt (3): either you use the single thread proxy, making (2) == (3), or you use the proxy, making (2) != (3) - regardless of the relationship between (1) and (2).

> 
> How are you ensuring that the compositor thread shuts down before the thread backing CompositorSupport?

For the renderer, nothing changes.
For the browser, by ensuring that we destroy WebLayerTreeViews, then we destroy the compositor WebThread (3) before we destroy the compositor client thread (2), which is the main thread anyway. We also ensure, client side, that the webkit main thread (1) is destroyed after that is done.
(note: threading is currently disabled when going through WebLayerTreeView, but a follow up patch will activate).

> 
> > Source/WebCore/platform/graphics/chromium/cc/CCMainThread.cpp:45
> > +    CompositorSupport::callOnMainThread(performTask, task.leakPtr());
> 
> hm, so you aren't using WTF::callOnMainThread() directly here any more?

Correct. Is that a problem? From my quick reading of the core, WTF::callOnMainThread is essentially a wrapper around WebKitSupport::callOnMainThread. Since we end up calling that in the renderer, nothing should change. But if it's a problem, we can go through WTF::callOnMainThread.

> 
> If so you should update the comment in CCMainThread.h, remove the #include <wtf/MainThread.h> from this .cpp,

Will do.

> and possibly go update CCLayerTreeHostTests to use your thread infrastructure instead of using webkit_support::'s main thread interaction functions.

That shouldn't be necessary, since we'll go through the same path given the current test harness.

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