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
This prevents the displayport accidentally being too large at high zoom
levels.
MozReview-Commit-ID: 66DVtOgS7N8
--HG--
extra : rebase_source : 70bd8098786bb9ad78a0f5b7efd83c796bb2e079
This patch adds a new pref, which controls the minimum velocity required on a fling
for it to accelerate a previous fling. This makes it so that a fast fling followed
by a very slow fling doesn't get accelerated. Also, update the AndroidAPZ code
to respect the pre-existing fling acceleration interval pref, which disallows
fling acceleration/flywheel if the two flings are too far apart in time.
MozReview-Commit-ID: 7sn57CufPZ4
