940977 - Tab animation performance depends on window size when using hardware acceleration

Status: RESOLVED WORKSFORME

(Core :: Graphics: Layers, defect)

Description

[Avi Halachmi (:avih)]

Tab animation performance appears to perform quite linearly with window size. The same behavior was confirmed on both windows 7 and OS X 10.8.5.

I performed the test using TART, with the the simple-fade test (pure tab css animation where nothing else happens). The window dimensions are of content area rather than the whole window, but still.

Here are my results (both with updated official nightly 2013-11-19):

Windows 7 with i7-3630qm, GPU HD4000 (on an nvidia optimus system):

Content: 1881 x 975 = 1.8Mpx
simpleFade-close-DPIcurrent.half.TART    Average (5): 3.26 stddev: 0.05
simpleFade-open-DPIcurrent.half.TART    Average (5): 4.60 stddev: 0.86

content: 425 x 38 = 0.16Mpx
simpleFade-close-DPIcurrent.half.TART    Average (5): 1.38 stddev: 0.04
simpleFade-open-DPIcurrent.half.TART    Average (5): 2.27 stddev: 0.06

Overall (close) interval ms =~ 1.36 + 1 * winAreaInMegaPx


OS X 10.8.5 on 2010 MBA:

425 x 39 = 16575 = 0.16M
simpleFade-close-DPIcurrent.half.TART    Average (10): 2.69 stddev: 0.28
simpleFade-open-DPIcurrent.half.TART    Average (10): 3.76 stddev: 0.51

1417 x 783 = 1109511 = 1.1M
simpleFade-close-DPIcurrent.half.TART    Average (10): 14.14 stddev: 1.23
simpleFade-open-DPIcurrent.half.TART    Average (10): 7.47 stddev: 1.16

Overall (close) interval ms =~ 0.74 + 12.18 * WinAreaInMegaPx


On both systems the formula stays valid with in-between window sizes, and also with different aspect ratios. However, on OS X it looks as if it's relatively much more affected by window size, i.e. with the window almost maximized, most of the perf seems to be due to the size (13.x ms) rather than due to the animation (0.74ms).

mstange also confirmed apparently similar behavior on a 2012 rMBP.


Do we expect such behavior? technically nothing on the screen changes except for a very small area of the closing/opening tab itself. Nothing at the tabstrip changes, and the content area is empty and doesn't change during the entire css fade in/out.

While it behaves similarly on both Windows 7 and OS X, it could be due to different technical reasons, but maybe the similarity is due to some common Gecko code.

Comment 1

[Matt Woodrow (:mattwoodrow)]

So, for accelerated layer managers/compositors (LayerManagerD3D10 and CompositorOGL I assume for these cases), we recomposite all the layers, regardless of what actually changed.

It has always been assumed that the high fill rate of GPU's would make it unnecessary to bother computing the dirty area of the window, and trying to limit compositing to that region.

This bug *may* be the first piece of contradicting evidence :)

Do we have any indication what the limiting factor is here? 

If it is the compositor, then we could copy the approach used in bug 882447. Apply those patches, and then use the clip region passed to BeginFrame to compute a scissor rect (I don't think converting the region to a rect will matter much here).

Comment 2

[Avi Halachmi (:avih)]

(In reply to Matt Woodrow (:mattwoodrow) from comment #1)
> So, for accelerated layer managers/compositors (LayerManagerD3D10 and
> CompositorOGL I assume for these cases) ...

Correct.

When I disabled HWA via the GUI and restarted, and using a big window, the windows 7 intervals went from 3.3ms (close) / 4.6ms (open) to 1ms / 2ms, and were not affected by window size (or maybe affected less than 0.1ms).

On the 2010 MBA, with a big window, intervals changed from 14ms (close) / 7ms (open) to ~17-18ms for both open and close, and also seemingly unaffected by window size.

Comment 3

[Jeff Muizelaar [:jrmuizel]]

It looks like most of these machines have integrated memory which makes the fact that this happens unsurprising. It may be possible to reduce the fill rate requirements using the trick that Matt suggests. This interface should also work:
http://msdn.microsoft.com/en-us/library/windows/desktop/hh446797%28v=vs.85%29.aspx

Comment 4

[Markus Stange [:mstange]]

Attachment: proof of concept

(In reply to Matt Woodrow (:mattwoodrow) from comment #1)
> If it is the compositor, then we could copy the approach used in bug 882447.
> Apply those patches, and then use the clip region passed to BeginFrame to
> compute a scissor rect (I don't think converting the region to a rect will
> matter much here).

This patch is a start on that route. On my rMBP (integrated GPU, big window size) it improves TART numbers by about 25% from about 8.7ms per frame to about 6.5ms per frame. The invalid rect calculation doesn't work completely correctly yet, so there are lots of artifacts during the animation, but the rect sizes don't look too far off. So I don't expect the right fix to get much better perf-wise.

The challenges with this approach are:
 - Double-buffering makes things a bit complicated. When we have three frames A B C, C needs to repaint diff(A, C), and not just diff(B, C). This patch does that by remembering diff(A, B) in mLastInvalidRect and repainting diff(A, B).Union(diff(B, C)) for frame C.
 - DrawWindowUnderlay/Overlay needs to be subject to the scissor rect, too. I moved the call to DrawWindowOverlay into Compositor::EndFrame for that.
 - The invalid region calculation doesn't seem to work perfectly yet. It doesn't seem to respect OMTA, for example.
 - Without the patch, LayerManagerComposite::EndTransaction fluffs out mInvalidRegion during the IPC layer transaction because mClonedLayerTreeProperties is null because LayerManagerComposite::BeginTransactionWithDrawTarget doesn't update it. Not sure how this is supposed to work.
 - We need to detect certain events that should invalidate the whole window, for example window resizes or GPU switching.