mirror of
https://gitlab.winehq.org/wine/wine-gecko.git
synced 2024-09-13 09:24:08 -07:00
bd4222b60e
This patch updates the logic in nsTransitionManager::FlushTransitions that deals with detecting newly-started (i.e. when the delay phase has just finished) or newly-finished animations. The existing logic had the following behavior: * Calling SetIsFinishedTransition for newly-finished transitions. This is no longer needed since by this point all consumers of IsFinishedTransition have been updated to use alternative means for testing if an animation is relevant. * Setting transitionStartedOrEnded to true so that we would post an animation restyle. We can achieve this same effect by simplying updating the canThrottleTick flag using the result of calling Animation::CanThrottle on each animation. Animation::CanThrottle will return false for a newly-started or newly-finished animation (it returns false for a newly-started animation since the animation's mIsRunningOnCompositor flag won't yet be true at that point.) * Updating the animation generation for newly-started and newly-finished animations in order to trigger a layer update. At least that appears to be the intention of this code. However, it currently has no effect since the animation generation on the pres context is not incremented in any context I could find where a newly started/finished animation might be detected. For this third case, this patch adds tests to ensure that transitions are correctly added and removed from the compositor when they start and finish. This is because most of the existing tests in test_animations_omta.html cover only CSS animations. As noted in the comments in the test, if a tick lands at the exact beginning of a transition we will typically not send it to the layer until the following tick because the RestyleManager will filter out the seemingly redundant change (i.e. no change to the computed style). Presumably updating the animation generation was intended to avoid this. This same behavior is true of CSS animations (and the same kind of comment appears elsewhere in test_animations_omta.html). Long-term this is probably worth fixing so that when a transition is triggered we get it to the compositor one tick earlier which should improve responsiveness when the main thread is busy and the interval between ticks is long. Furthermore, we should do the same for both all type of animations, not just transitions. Currently, however, this patch preserves the existing behavior and helps narrow the difference between transitions and animations so we can apply this optimization to both. |
||
|---|---|---|
| .. | ||
| base | ||
| build | ||
| doc | ||
| forms | ||
| generic | ||
| inspector | ||
| ipc | ||
| mathml | ||
| media | ||
| printing | ||
| reftests | ||
| style | ||
| svg | ||
| tables | ||
| tools | ||
| xul | ||
| moz.build | ||