mirror of
https://gitlab.winehq.org/wine/wine-gecko.git
synced 2024-09-13 09:24:08 -07:00
a2f97c232b
This changes the behavior of the CanPerformOnCompositorThread methods of both ElementAnimations and ElementTransitions to check that the respective animations or transitions are actually running. This is ok because: - The main caller is nsLayoutUtils::HasAnimationsForCompositor, and all of its callers pretty clearly want the more restricted behavior (they're concerned with layer activity) - The only other callers of these functions are nsAnimationManager::FlushAnimations and nsTransitionManager::FlushTransitions (determining when to do throttling), nsAnimationManager::GetAnimationsForCompositor (whose only caller, nsDisplayListBuilder::AddAnimationsAndTransitionsToLayer, also checks IsRunningAt). I think these also all want or are fine with having the IsRunningAt check. As to the actual changes: - In the animation manager, I think it's a mistake that ElementAnimation::IsRunningAt didn't already check mIterationDuration, since we throw out animations with a bad iteration-duration in ElementAnimations::EnsureStyleRuleFor. So this makes that change as well. - In the transition manager, IsRunningAt already checks !IsRemovedSentinel(). I've confirmed in gdb on a device that this fixes the repeated nsIFrame::SchedulePaint calls that were the symptom of this bug. I believe this patch also makes it so that a short animation of a property that can't be animated on the compositor doesn't prevent the entire duration of the animation of a property that can from being throttled (having the main thread style updates suppressed). |
||
|---|---|---|
| .. | ||
| analysis | ||
| base | ||
| build | ||
| doc | ||
| forms | ||
| generic | ||
| inspector | ||
| ipc | ||
| mathml | ||
| media | ||
| printing | ||
| reftests | ||
| style | ||
| svg | ||
| tables | ||
| tools | ||
| xul | ||
| moz.build | ||