Bug 60508 - [chromium] Make throttling of WebGL based on webgl frames, not compositor frames
Summary: [chromium] Make throttling of WebGL based on webgl frames, not compositor frames
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: New Bugs (show other bugs)
Version: 528+ (Nightly build)
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Nat Duca
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-05-09 14:53 PDT by Nat Duca
Modified: 2011-05-11 15:51 PDT (History)
7 users (show)

See Also:


Attachments
Patch (15.15 KB, patch)
2011-05-09 15:02 PDT, Nat Duca
no flags Details | Formatted Diff | Diff
Use timer. (14.21 KB, patch)
2011-05-09 19:16 PDT, Nat Duca
no flags Details | Formatted Diff | Diff
Make it build. (14.19 KB, patch)
2011-05-09 19:48 PDT, Nat Duca
no flags Details | Formatted Diff | Diff
remove comments. (14.12 KB, patch)
2011-05-09 20:16 PDT, Nat Duca
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Nat Duca 2011-05-09 14:53:21 PDT
[chromium] Make throttling of WebGL based on webgl frames, not compositor frames
Comment 1 Nat Duca 2011-05-09 15:02:36 PDT
Created attachment 92859 [details]
Patch
Comment 2 James Robinson 2011-05-09 15:11:19 PDT
Comment on attachment 92859 [details]
Patch

WebCore code normally uses a WebCore::Timer() with a delay of 0 to do this sort of callback - will this work in this case?  I believe this will take care of your layer lifetime issues.

For an example see Document::m_styleRecalcTimer
Comment 3 Nat Duca 2011-05-09 19:16:08 PDT
Created attachment 92908 [details]
Use timer.
Comment 4 WebKit Review Bot 2011-05-09 19:42:17 PDT
Comment on attachment 92908 [details]
Use timer.

Attachment 92908 [details] did not pass chromium-ews (chromium-xvfb):
Output: http://queues.webkit.org/results/8646807
Comment 5 Nat Duca 2011-05-09 19:48:23 PDT
Created attachment 92910 [details]
Make it build.
Comment 6 James Robinson 2011-05-09 19:53:51 PDT
Comment on attachment 92910 [details]
Make it build.

View in context: https://bugs.webkit.org/attachment.cgi?id=92910&action=review

Some nits for now.  I think it looks OK but think that Ken should do the final review.

> Source/WebCore/platform/graphics/chromium/WebGLLayerChromium.cpp:146
> +    // Check if the context is gone.

WebKit style frowns on this sort of comment since it should be obvious what the check is doing just by reading the conditional.

> Source/WebCore/platform/graphics/chromium/WebGLLayerChromium.cpp:150
> +    // Actually do the rate limiting.

WK style isn't too fond of this either.

> Source/WebCore/platform/graphics/chromium/WebGLLayerChromium.cpp:152
> +    extensions->rateLimitOffscreenContextCHROMIUM();

What if we lose the context while the task is pending?  Does anything special happen?
Comment 7 Nat Duca 2011-05-09 20:15:33 PDT
This extension should behave similarly to other GL APIs upon context lost: it will fail, but it shouldn't explode. Our Chromium-side implementation of the extension should hold to that standard.

I verified that this is the case with the chromium-side of the implementation.
Comment 8 Nat Duca 2011-05-09 20:16:21 PDT
Created attachment 92912 [details]
remove comments.
Comment 9 Kenneth Russell 2011-05-11 13:41:55 PDT
Comment on attachment 92912 [details]
remove comments.

Looks great. r=me
Comment 10 WebKit Commit Bot 2011-05-11 15:47:38 PDT
The commit-queue encountered the following flaky tests while processing attachment 92912 [details]:

http/tests/misc/favicon-loads-with-icon-loading-override.html bug 58412 (author: alice.liu@apple.com)
The commit-queue is continuing to process your patch.
Comment 11 WebKit Commit Bot 2011-05-11 15:51:08 PDT
Comment on attachment 92912 [details]
remove comments.

Clearing flags on attachment: 92912

Committed r86278: <http://trac.webkit.org/changeset/86278>
Comment 12 WebKit Commit Bot 2011-05-11 15:51:12 PDT
All reviewed patches have been landed.  Closing bug.