Open Bug 790592 Opened 13 years ago Updated 3 years ago

OMTA doesn't start right away, waits for the refresh driver

Categories

(Core :: Layout, defect)

x86
macOS
defect

Tracking

()

People

(Reporter: BenWa, Unassigned)

References

Details

OMTA doesn't start right when the transition class is set but has to wait until the refresh driver draws. This is a problem for designing an OMTA tab strip because any jank between JS setting up the animation and the refresh driver causes a delay in starting the animation which can skips several of the first few frames. This means that the compositor can't start the async transition on time.
This looks to be something that lucasr has been running into trying to get a smooth fade transition using just css for reader mode (this is without OMTA, just in general). This is a pretty general problem when you have synchronous layout engines - The way I usually deal with it from an app perspective is to only start timing the animation after the first frame is drawn. Obviously, you should try and get any expensive work out of the way before starting an animation, but this is an easy way to mitigate some of the harder problems. Can we get CSS animations timing only after the first frame is drawn?
This particular case could be fixed by invalidating frames/pushing empty layers transactions when the class is set on an element. However, this doesn't solve the more general case (mutating the DOM to make a transition/animation CSS rule apply). Matt, could we push empty layers transactions when the DOM changes, or is that too expensive?
I'm not entirely sure I understand the problem here. The delay between setting an animation, and the refresh driver running should never be more than 1 frame. Unless something is blocking for a long period of time - initial layout for example. We could only consider pushing an empty transaction if the animation property change was the only layout change during that frame, something that wouldn't be true during initial layout. Chris' approach sounds like it would be more effective given the current information.
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.