[chromium] Use WebCompositor interface in Platform API instead of CCProxy to query threaded compositor status
Created attachment 157013 [details] Patch
Comment on attachment 157013 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=157013&action=review > Source/Platform/chromium/public/WebCompositor.h:53 > + // Debug only - always returns true in release builds. > + // Returns whether we're currently running on the compositor thread. > + WEBKIT_EXPORT static bool onCompositorThread(); this feels a little bit skeevy. The implementation code is currently all guarded by #ifndef NDEBUG, and the only caller to this is doing an ASSERT(). One option would be to hide the API itself behind debug-only compile time guards, or decide that the callsite isn't really worth having the API (it's in WebMediaPlayerClientImpl if you want to take a look).
Please wait for approval from abarth@webkit.org, dglazkov@chromium.org, fishd@chromium.org, jamesr@chromium.org or tkent@chromium.org before submitting, as this patch contains changes to the Chromium public API. See also https://trac.webkit.org/wiki/ChromiumWebKitAPI.
Comment on attachment 157013 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=157013&action=review >> Source/Platform/chromium/public/WebCompositor.h:53 >> + WEBKIT_EXPORT static bool onCompositorThread(); > > this feels a little bit skeevy. The implementation code is currently all guarded by #ifndef NDEBUG, and the only caller to this is doing an ASSERT(). One option would be to hide the API itself behind debug-only compile time guards, or decide that the callsite isn't really worth having the API (it's in WebMediaPlayerClientImpl if you want to take a look). I'd probably just remove it.
Sounds reasonable to me. +cc as an FYI
Committed r124925: <http://trac.webkit.org/changeset/124925>