Closed
Bug 943962
Opened 11 years ago
Closed 11 years ago
tscroll-ASAP regression on inbound for osx 10.6 and 10.8
Categories
(Core :: Graphics, defect)
Tracking
()
RESOLVED
WORKSFORME
People
(Reporter: jmaher, Unassigned)
References
Details
(Keywords: perf, regression, Whiteboard: [talos_regression])
dev.tree-management has a regression posted for osx tscroll-asap:
https://groups.google.com/forum/#!topic/mozilla.dev.tree-management/slM4mBYpdHU
this is not too surprising, but not expected from bug 943041:
http://hg.mozilla.org/integration/mozilla-inbound/rev/93d937df1409
you can see the details of which tests have regressed:
https://datazilla.mozilla.org/?start=1384967153&stop=1385571953&product=Firefox&repository=Mozilla-Inbound&os=mac&os_version=OS%20X%2010.8&test=tscrollx&graph_search=93d937df1409&tr_id=3690122&graph=iframe.svg&project=talos
specifically:
iframe.svg
tiled-fixed-downscale.html
tiled-fixed.html
tiled.html
sources can be found here:
http://hg.mozilla.org/build/talos/file/d4f9651aff7b/talos/page_load_test/scroll
this doesn't seem to affect other platforms.
Comment 1•11 years ago
|
||
I don't yet understand what's happening here.
Tscrollx turns on ASAP mode (layout.frame_rate = 0) and measures frames by counting requestAnimationFrame callback invocations.
Before bug 943041, turning on ASAP mode only affected the main thread, not the compositor thread. Now it affects both. However, the patch shouldn't have had any effect on what happens on the main thread (I think), and since the test only measures main thread stuff, it shouldn't have regressed.
Matt, do you know of a reason why this could have affected the main thread?
I profiled a local Talos run but I couldn't see anything unexpected.
Comment 2•11 years ago
|
||
That said, it seems main thread ASAP is much faster than compositor ASAP... during the test it looks like this:
ShadowLayerForwarder::EndTransaction()
ShadowLayerForwarder::EndTransaction()
ShadowLayerForwarder::EndTransaction()
ShadowLayerForwarder::EndTransaction()
ShadowLayerForwarder::EndTransaction()
ShadowLayerForwarder::EndTransaction()
ShadowLayerForwarder::EndTransaction()
ShadowLayerForwarder::EndTransaction()
ShadowLayerForwarder::EndTransaction()
ShadowLayerForwarder::EndTransaction()
ShadowLayerForwarder::EndTransaction()
CompositorParent::Composite()
ShadowLayerForwarder::EndTransaction()
ShadowLayerForwarder::EndTransaction()
ShadowLayerForwarder::EndTransaction()
ShadowLayerForwarder::EndTransaction()
ShadowLayerForwarder::EndTransaction()
ShadowLayerForwarder::EndTransaction()
ShadowLayerForwarder::EndTransaction()
ShadowLayerForwarder::EndTransaction()
ShadowLayerForwarder::EndTransaction()
ShadowLayerForwarder::EndTransaction()
ShadowLayerForwarder::EndTransaction()
ShadowLayerForwarder::EndTransaction()
ShadowLayerForwarder::EndTransaction()
CompositorParent::Composite()
[...]
In other words, we produce 10x as many frames as we get to composite, if I understand this correctly.
Comment 3•11 years ago
|
||
The OSX GLContext is probably still blocking on vsync inside SwapBuffers isn't it?
We have asynchronous transactions for OSX, so we're just queuing them up while the compositor thread is blocked.
Comment 4•11 years ago
|
||
(In reply to Matt Woodrow (:mattwoodrow) from comment #3)
> The OSX GLContext is probably still blocking on vsync inside SwapBuffers
> isn't it?
It doesn't in ASAP: http://mxr.mozilla.org/mozilla-central/source/gfx/gl/GLContextProviderCGL.mm#158
Comment 5•11 years ago
|
||
(In reply to Matt Woodrow (:mattwoodrow) from comment #3)
> The OSX GLContext is probably still blocking on vsync inside SwapBuffers
> isn't it?
We turn off vsync in ASAP mode, but I expect that we spend most of our time in SwapBuffers anyway.
Hmm, this all sounds like it would be a good idea to use FrameTimeRecording for tscrollx, too, so that we can start to measure the frames that we actually present, and not those we produce.
Reporter | ||
Comment 6•11 years ago
|
||
it appears we have fixed this in general:
http://graphs.mozilla.org/graph.html#tests=[[287,63,21]]&sel=none&displayrange=365&datatype=running
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Updated•11 years ago
|
Resolution: FIXED → WORKSFORME
You need to log in
before you can comment on or make changes to this bug.
Description
•