Joel Maher ( :jmaher ) (UTC -8) Reporter
	Description • 11 years ago

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.

	Markus Stange [:mstange]
	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.

	Markus Stange [:mstange]
	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.

	Matt Woodrow (:mattwoodrow)
	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.

	Avi Halachmi (:avih)
	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

	Markus Stange [:mstange]
	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.

	Joel Maher ( :jmaher ) (UTC -8) Reporter
	Comment 6 • 10 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