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

[bugzilla-daemon at webkit.org]

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


Darin Fisher (:fishd, Google) <fishd at chromium.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
 Attachment #110204|review?                     |review-
               Flag|                            |




--- Comment #24 from Darin Fisher (:fishd, Google) <fishd at chromium.org>  2011-10-11 10:51:16 PST ---
(From update of attachment 110204)
View in context: https://bugs.webkit.org/attachment.cgi?id=110204&action=review

> Source/WebCore/platform/graphics/chromium/CompositorSupport.cpp:34
> +    return s_delegate->currentTime();

Instead of thunking through a Delegate interface, we normally just move the
implementation of these methods to WebKit/chromium/src, so that we can call
WebKit APIs directly.  it avoids the need to define the intermediate vtable.

> Source/WebKit/chromium/public/WebKit.h:78
> +WEBKIT_EXPORT void initializeCompositor(WebCallOnMainThreadFunc);

it seems like these should be methods on WebCompositor.  we already have WebCompositor::setThread.
it seems like you can do the WebCore::CCProxy::setMainThread(currentThread()) call there, if we
don't already.  it seems like WebCompositor could have a static method for setting the
WebCompositorSupport interface.  also, perhaps the CallOnMainThread support should be provided
via WebCompositorSupport instead?

maybe WebCompositor::setThread should be changed to WebCompositor::initialize?

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