RESOLVED FIXED67621
[chromium] REGRESSION(94353): requestAnimationFrame not throttled in compositing path
https://bugs.webkit.org/show_bug.cgi?id=67621
Summary [chromium] REGRESSION(94353): requestAnimationFrame not throttled in composit...
James Robinson
Reported 2011-09-05 18:00:33 PDT
See http://webstuff.nfshost.com/anim-timing/raftime.html. When compositing is enabled, requestAnimationFrame is uncapped. Regression range is 94351 - 94379. Will bisect.
Attachments
Patch (3.05 KB, patch)
2011-09-06 11:34 PDT, Nat Duca
no flags
Okay (1.92 KB, patch)
2011-09-06 11:57 PDT, Nat Duca
jamesr: review+
jamesr: commit-queue+
James Robinson
Comment 1 2011-09-05 20:34:16 PDT
Locally confirmed that it's http://trac.webkit.org/changeset/94353. I'm not really sure how...
Nat Duca
Comment 2 2011-09-05 22:18:51 PDT
Oy! Well I guess we know what I'm doing on Tuesday then. :)
Nat Duca
Comment 3 2011-09-06 11:34:24 PDT
James Robinson
Comment 4 2011-09-06 11:42:48 PDT
Comment on attachment 106452 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=106452&action=review > Source/WebCore/platform/graphics/chromium/cc/CCSingleThreadProxy.cpp:91 > + commitIfNeeded(false); actually we don't want to do layout here either. it's the responsibility of the caller to WebWidget::paint() to call animateAndLayout() before calling this function > Source/WebCore/platform/graphics/chromium/cc/CCSingleThreadProxy.cpp:237 > + if (!alreadyCalledLayout) > + m_layerTreeHost->animateAndLayout(frameBeginTime); i think you can just delete this completely
Nat Duca
Comment 5 2011-09-06 11:55:08 PDT
> i think you can just delete this completely I did this because we're going to have to eventually invert that. But, I'll do as you wish.
James Robinson
Comment 6 2011-09-06 11:56:54 PDT
Eventually we'll need it, but not for compositeAndReadback(). That path will not.
Nat Duca
Comment 7 2011-09-06 11:57:05 PDT
Nat Duca
Comment 8 2011-09-06 12:02:41 PDT
Note You need to log in before you can comment on or make changes to this bug.