[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 #10 from Antoine Labour <piman at chromium.org>  2011-09-28 20:46:35 PST ---
(In reply to comment #7)
> (From update of attachment 109111 [details])
> CCProxy::setMainThread is debug-only, so you'll have to add #ifndef NDEBUGs in CompositorSupport::initialize() / CompositorSupport::shutdown().

Done. My bad.

> Otherwise I think this looks pretty reasonable.  I do wonder about the combination of need v8 / need compositor - feels like we're growing a bit oddly there.  Also, don't we initialize WebKit with v8 on in the browser process in order to do PAC resolution?

Today, AFAICT we initialize it without V8, see http://codesearch.google.com/#OAMlx_jo-ck/src/content/browser/in_process_webkit/webkit_thread.cc&exact_package=chromium&q=WebKit::initialize&type=cs
I think that's the raison d'être of this call.
I'm absolutely not attached to the "initializeWithoutV8AndCompositor" concept. I didn't want to "sneak in" the compositor initialization. My plan was to update the browser-side webkit initialization to use initializeWithoutV8AndCompositor and then remove the initializeWithoutV8 call altogether.
I do agree that cherry-picking what we initialize and encoding that in the name is a bit clunky. We could call it "initializeForBrowser" or something...
One option is to have a bitfield of webkit sub-modules that we want to initialize, though I suspect that's going to add a bunch of untested (and most likely not working) combinations.
Any good idea?

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