mirror of
https://github.com/mozilla/gecko-dev.git
synced 2024-11-08 12:37:37 +00:00
Read-only Git mirror of the Mercurial gecko repositories at https://hg.mozilla.org. How to contribute: https://firefox-source-docs.mozilla.org/contributing/contribution_quickref.html
fb0d9d7187
Normally animation players get times from their timeline which is based on the refresh driver for their associated document. However, for animations that we time from when their first frame has been rendered, we want to record the actual time when painting finished as their start time. If we wait until the next refresh driver tick then the delay between playing an animation and its actual start will be too great. In this patch, we introduce a mechanism for fast-forwarding a timeline to a time between the current refresh driver time and the next refresh driver tick. By adjusting the timeline rather than the player we maintain a consistent state (in fact, if we just naively set the animation player start time to the timestamp value we recorded when painting finished it will appear to start in the future and the animation will temporarily jump from playing, to waiting to start, then back to playing again on the next refresh driver tick). To be completely consistent, however, when we fast-forward the timeline we should tell all animation players listening to the timeline to mark their target element as needing a style flush. Otherwise we may be able to observe an inconsistency between some animation players' current time and the computed style of their targets. We don't, however, currently know which players are observing a given timeline. We will likely introduce that in the near future (in order to implement AnimationTimeline.getAnimationPlayers) and fix the inconsistency in timing then. A test later in the patch series verifies this inconsistency so it is easy to fix in future. An alternative approach would be to simply record the time when animation should start, send that time to the compositor but don't actually update the animation start time on the main thread until the subsequent refresh driver tick. Such an approach is complex as it introduces an additional state--"finished pending but not yet started". We will attempt to switch to that approach in bug 1112480. |
||
---|---|---|
accessible | ||
addon-sdk | ||
b2g | ||
browser | ||
build | ||
caps | ||
chrome | ||
config | ||
content | ||
db/sqlite3 | ||
docshell | ||
dom | ||
editor | ||
embedding | ||
extensions | ||
gfx | ||
hal | ||
image | ||
intl | ||
ipc | ||
js | ||
layout | ||
media | ||
memory | ||
mfbt | ||
mobile | ||
modules | ||
mozglue | ||
netwerk | ||
nsprpub | ||
other-licenses | ||
parser | ||
probes | ||
profile | ||
python | ||
rdf | ||
security | ||
services | ||
startupcache | ||
storage | ||
testing | ||
toolkit | ||
tools | ||
uriloader | ||
view | ||
webapprt | ||
widget | ||
xpcom | ||
xpfe | ||
xulrunner | ||
.clang-format | ||
.clang-format-ignore | ||
.gdbinit | ||
.gitignore | ||
.hgignore | ||
.hgtags | ||
.lldbinit | ||
aclocal.m4 | ||
Android.mk | ||
AUTHORS | ||
client.mk | ||
client.py | ||
CLOBBER | ||
configure.in | ||
LEGAL | ||
LICENSE | ||
mach | ||
Makefile.in | ||
moz.build | ||
mozilla-config.h.in | ||
README.txt |
An explanation of the Mozilla Source Code Directory Structure and links to project pages with documentation can be found at: https://developer.mozilla.org/en/Mozilla_Source_Code_Directory_Structure For information on how to build Mozilla from the source code, see: http://developer.mozilla.org/en/docs/Build_Documentation To have your bug fix / feature added to Mozilla, you should create a patch and submit it to Bugzilla (https://bugzilla.mozilla.org). Instructions are at: http://developer.mozilla.org/en/docs/Creating_a_patch http://developer.mozilla.org/en/docs/Getting_your_patch_in_the_tree If you have a question about developing Mozilla, and can't find the solution on http://developer.mozilla.org, you can try asking your question in a mozilla.* Usenet group, or on IRC at irc.mozilla.org. [The Mozilla news groups are accessible on Google Groups, or news.mozilla.org with a NNTP reader.] You can download nightly development builds from the Mozilla FTP server. Keep in mind that nightly builds, which are used by Mozilla developers for testing, may be buggy. Firefox nightlies, for example, can be found at: ftp://ftp.mozilla.org/pub/firefox/nightly/latest-trunk/ - or - http://nightly.mozilla.org/