We needed this polyfill for <initializer_list> when some of our C++
standard libraries did not support said header. They all do now, so the
polyfill is redundant.
This is useful for talos tests that record checkerboarding. In those tests, the
page might still be in a checkerboard state at the end of the test, so it may be
necessary to flush out the report for measurement.
MozReview-Commit-ID: CtafG4NAGHN
If, within a single refresh driver tick, the scroll position is updated by JS
explicitly, and then subsequently also updated by a frame reconstruction, the
scroll origin from the former (nsGkAtoms::other) can get clobbered by the latter
(to nsGkAtoms::restore). The restore scroll origin is "weaker" in that it can
be ignored by the APZ code in some circumstances. This is undesirable because
it means the JS scroll update also gets ignored. This patch ensures that when
setting the scroll origin we don't do this clobbering of stronger origins with
weaker origins.
MozReview-Commit-ID: DA4EHp1Debu
--HG--
extra : rebase_source : 99fd1f91698a605792b2a622450f1ff31bc89101
We are forcing a crash when we fail to bind a texture to a
framebuffer. Although it is not clear why this step is failing, crashing
is too drastic an action.
Instead, return nullptr as is done for every other possible failure
during this function. Also log a gfxCriticalError, which will hopefully
allow us to find the cause of the failure at some point, while not
crashing for release users.
MozReview-Commit-ID: H1RlFz8ZVbU
We need to consider fill mode in compositor thread as well as other properties
because pulling the animation back from the compositor thread is sometimes
delayed due to the main thread busyness. In such situations, if there is
another animation running on the main thread on the same element, users can
easily notice a gap between both of animations.
MozReview-Commit-ID: 1i7YTWboira
--HG--
extra : rebase_source : 036ca7707d07200af7435e027607503cd03f547e
The check of negative elapsedDuration is basically no longer valid since
animation delay is not factored into start time any more. But still we have
somtimes met negative elapsedDuration sice we use a previous vsync time stamp
for async animations to make the animations more sync. This is not a problem
in most cases but makes two reftests intermitent failure because both of them
used steps(1, start), the steps(1, start) composed different results in the
before phase and in the active phase. To avoid this difference this patch
replace the steps(1, start) with steps(1, end).
Once we incorpolate playbackRate into GetCurrentOrPendingStartTime, we don't
need to call AnimationTimeToTimeStamp for deviding delay by playbackRate since
the time passed to AnimationTimeToTimeStamp does not contain delay any more.
MozReview-Commit-ID: IVE2IFfNgm0
--HG--
extra : rebase_source : 7cb42e57067c21451706bd89284016d996dc8b12
Phil Ringnalda
Kartikaya Gupta
Mason Chang
Andi-Bogdan Postelnicu
Nathan Froyd
Sotaro Ikeda
Daosheng Mu
Carsten "Tomcat" Book
David Anderson
Sebastian Hengst
Wes Kocher
Brian Hackett
Kearwood (Kip) Gilbert
stefanh@inbox.com
Ethan Lin
Jamie Nicol
Sylvestre Ledru
Hiroyuki Ikezoe
Nicolas Silva