I definitely agree with this, but we also need OMTAnimations to be
finished and enabled before any of the interesting parts of the UI can
be converted.
Given that, I don't think we can have this conversation at the expense
of trying to fix the current set of regressions from OMTC.
We may also want to invest some time into writing tools to help authors
write and debug animations that run efficiently, and without main-thread
involvement.
- Matt
On 30/05/14 2:30 pm, Andreas Gal wrote:
I think we should shift the conversation to how we actually animate here.
Animating by trying to reflow and repaint with 60fps is just a bad idea. This
might work on very high end hardware, but it will cause poor performance on the
low-end Windows notebooks people buy these days. In other words, I am pretty
sure our animation here was bad for a lot of our users pre-OMTC.
OMTC enables us to do smooth 60fps animations even under high load and even on
very low end hardware, as long we do the animation right. So lets focus on that
and figure out how to draw a tab strip that doesn’t hit pathological repainting
paths.
I see two options here. We have to change our UX such that we can execute a
smooth animation on the compositor (transforms, opacity changes, filter
effects, etc), or we should draw the tab strip with canvas, which is more
suitable for complex custom animations than reflow.
Andreas
On May 29, 2014, at 10:14 PM, avi...@gmail.com wrote:
So, wrt TART, I now took the time to carefully examine tab animation visually
on one system.
TL;DR:
- I think OMTC introduces a clearly visible regression with tab animation
compared to without OMTC.
- I _think_ it regresses more with tab close than with tab open animation.
- The actual throughput regression is probably bigger than indicated by TART
numbers.
The reason for the negative bias is that the TART results are an average of 10
different animations, but only one of those is close to pure graphics perf
numbers, and when you look only on this test, the regression is bigger than
50-100% (more like 100-400%).
The details:
System: Windows 8.1 x64, i7-4500u, using Intel's iGPU (HD4400), and with
official Firefox nightly 32bit (2014-05-29).
First, visually: both with and without ASAP mode, to my eyes, tab animation
with OMTC is less smooth, and seems to have lower frame rate than without OMTC.
As for what TART measures, of all the TART subtests, there are 3 which are most
suitable for testing pure graphics performance - they test the css fade-in and
fade-out (that's the close/open animation) of a tab without actually opening or
closing a browser tab, so whatever performance it has, the limit comes only
from the animation itself and it doesn't include other overheads.
These tests are the ones which have "fade" in their name, and only one of them
is enabled by default in talos - the other two are available only when running TART
locally and then manually selecting animations to run.
I'll focus on a single number which is the average frame interval of the entire animation
(these are the ".all" numbers), for the fade animation at default DPI (which is
1 on my system - so the most common).
What TART measures locally on my system:
OMTC without ASAP mode (as out of the box config as it gets):
iconFade-close-DPIcurrent.all Average (5): 18.91 stddev: 0.86
iconFade-open-DPIcurrent.all Average (5): 17.61 stddev: 0.78
OMTC with ASAP:
iconFade-close-DPIcurrent.all Average (5): 18.47 stddev: 0.46
iconFade-open-DPIcurrent.all Average (5): 10.08 stddev: 0.46
While this is an average of only 5 runs, stddev shows it's reasonably
consistent, and the results are also consistent when I tried more.
We can already tell that close animation just doesn't get below ~18.5ms/frame
on this system, ASAP doesn't affect it at all. We can also see that the open
animation is around 60fps without ASAP (17.6 can happen with our inaccurate
interval timers) and with ASAP it goes down to about 10ms/frame.
Without OMTC and without ASAP:
iconFade-close-DPIcurrent.all Average (5): 16.54 stddev: 0.16
iconFade-open-DPIcurrent.all Average (5): 16.52 stddev: 0.12
Without OMTC and with ASAP:
iconFade-close-DPIcurrent.all Average (5): 5.53 stddev: 0.07
iconFade-open-DPIcurrent.all Average (5): 6.37 stddev: 0.08
The results are _much_ more stable (stddev), and quite lower (in ASAP) and closer to 16.7
in "normal" mode.
While I obviously can't visually notice differences when the frame rate is
higher than my screen's 60hz, from what I've seen so far, both visually and at
the numbers, I think TART is not less reliable than before, it doesn't look to
me as if ASAP introduces very bad bias (I couldn't deduct any), and OMTC does
seem regress tab animations meaningfully.
- avih
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
