The spec is still using `Scroll-linked`, so we exclude the change of WPT tests.
I believe WPT will get updates once the spec doc is renamed.
Differential Revision: https://phabricator.services.mozilla.com/D165914
Basically, we need to detect a case if there is only scroll animations
which are not sampled because it goes back to before phase. If this
happens, we set ScrollToDelay to |mReason| in the returned value.
Without this patch, the visual result is intermittent because it
is possible that there are new animations arrived at the moment when
scrolling from active phase to before phase.
We don't have a test for after phase because we don't support end delay
for scroll animations now. However, although we set the adjusted fill, we may
still need this in the future so let's keep the check of after phase for now.
Differential Revision: https://phabricator.services.mozilla.com/D155108
We sample the scroll-linked animations on the compositor thread, by the
sampled scroll offsets from the AsyncPanZoomController of its scrollable
frame.
Differential Revision: https://phabricator.services.mozilla.com/D139775
This makes the naming more consistent with other functions called
Insert and/or Update. Also, it removes the ambiguity whether
Put expects that an entry already exists or not, in particular because
it differed from nsTHashtable::PutEntry in that regard.
Differential Revision: https://phabricator.services.mozilla.com/D105473
This allows it to be forward-declared (while a nested class cannot be),
such that headers files that use RectCallback by pointer or reference
do not need to include nsLayoutUtils.h.
This avoids including nsLayoutUtils.h in nsRange.h.
Differential Revision: https://phabricator.services.mozilla.com/D91685
With the previous change, on WebRender AnimationTransform::mTransformInDevSpace
and AnimationTransform::mFrameTransform are pretty much same, so we don't need
to set both of values, we need only mFrameTransform.
Also this patch drops move(s), I didn't know that Matrix4x4 can't be moved.
Differential Revision: https://phabricator.services.mozilla.com/D83041
The machinery to report janked animations is;
1) Store the partial pre-rendered animation id and the Animation object in a
hashtable in LayerManager
2) Store the animation id in the Animation object as well
3) When we detect jank, we send the animation id to the main-thread via an IPC
call
4) Find the Animation object with the id in the hashtable and update the
Animaiton
5) Whenever the partial pre-rendered Animation stop running on the compositor
i.e. the Animation finished normally, the Animation's target element is
changed, etc. etc., remove the Animation from the hashtable
Depends on D75731
Differential Revision: https://phabricator.services.mozilla.com/D75732
The machinery to report janked animations is;
1) Store the partial pre-rendered animation id and the Animation object in a
hashtable in LayerManager
2) Store the animation id in the Animation object as well
3) When we detect jank, we send the animation id to the main-thread via an IPC
call
4) Find the Animation object with the id in the hashtable and update the
Animaiton
5) Whenever the partial pre-rendered Animation stop running on the compositor
i.e. the Animation finished normally, the Animation's target element is
changed, etc. etc., remove the Animation from the hashtable
Differential Revision: https://phabricator.services.mozilla.com/D75732
Now CompositorAnimationStorage::GetAnimatedValue() and SetAnimatedValue()s
are called on the sampler thread in case of WebRender, are called on the
compositor thread in case of non WebRender, so we drop assertions of
IsInCompositorThread check there. A mLock.AssertCurrentThreadOwns call in
each function should make sure the function gets called on the
sampler/compositor thread with acquiring the lock.
One caveat in this change is that in case we try to get an animation value via
nsIDOMWindowUtils.getOMTAStyle(), we do sample animations on the _compositor_
thread and we never call UpdateDynamicProperties, which means if it gets called
in testing refresh driver mode, visual results will differ from what the value
returned by the getOMTAStyle should look like. But it should be fine because we
disallow using any chrome priviledge APIs in reftests and also we will never use
the testing refresh driver mode in the reftest harness. Also in mochitests the
visual results' differences might make people confusing if the person can notice
it, but in principal getOMTAStyle() is designed to get computed animating values
so that it doesn't matter what the visual result is.
Differential Revision: https://phabricator.services.mozilla.com/D79982
Boris Chiou
Florian Quèze
Botond Ballo
Matt Woodrow
Simon Giesecke
Hiroyuki Ikezoe
Brindusan Cristian
Sylvestre Ledru