mirror of
https://github.com/mozilla/gecko-dev.git
synced 2024-11-24 05:11:16 +00:00
ec7a1d06ff
Instead of starting transitions and animations as a result of a paint, use the refresh driver tick to do this. This sets the transition-ready time to the current time during the next refresh driver tick that it was started on (see mSawTickWhilePending). This is similar to what's described in the bugs comments, and seems to work nicely in practice. We could easily change that (current time) by a paint-based time if needed (when available), which would be more similar to what we were doing. But I'd rather do the simple thing for now, and land this shortly after the soft freeze is over so that we have time to watch out for regressions. There's one regression on a test that birtles wrote (using an XHR doc and switching the timeline to a rendered doc's timeline). We use the timeline's document rather than the target document to determine whether to trigger animations now. That's one of the cases where we'd keep vsync perma-running without this patch, and Chrome also fails that test. Maybe the test should be removed / the spec should be tweaked to allow this behavior? This causes some progression in some CSS transitions tests too, and I added an extra test for the vsync behavior. Over-all this is much simpler to reason about and I think we should try to do this. Differential Revision: https://phabricator.services.mozilla.com/D193583 |
||
|---|---|---|
| .. | ||
| client | ||
| docs | ||
| perfdocs | ||
| platform | ||
| server | ||
| shared | ||
| startup | ||
| .eslintrc.js | ||
| .eslintrc.xpcshell.js | ||
| CODE_OF_CONDUCT.md | ||
| moz.build | ||
| rename.py | ||
| templates.mozbuild | ||
| tsconfig.json | ||