RESOLVED FIXED 93398
[chromium] Use WebCompositor interface in Platform API instead of CCProxy to query threaded compositor status
https://bugs.webkit.org/show_bug.cgi?id=93398
Summary [chromium] Use WebCompositor interface in Platform API instead of CCProxy to ...
James Robinson
Reported 2012-08-07 14:49:01 PDT
[chromium] Use WebCompositor interface in Platform API instead of CCProxy to query threaded compositor status
Attachments
Patch (12.91 KB, patch)
2012-08-07 14:50 PDT, James Robinson
abarth: review+
James Robinson
Comment 1 2012-08-07 14:50:49 PDT
James Robinson
Comment 2 2012-08-07 14:52:12 PDT
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).
WebKit Review Bot
Comment 3 2012-08-07 14:52:32 PDT
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.
Adam Barth
Comment 4 2012-08-07 14:54:43 PDT
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.
James Robinson
Comment 5 2012-08-07 14:59:47 PDT
Sounds reasonable to me. +cc as an FYI
James Robinson
Comment 6 2012-08-07 15:01:55 PDT
Note You need to log in before you can comment on or make changes to this bug.