1128112 - Delay the start of OMTA-able animations and transitions until images that may be painted during them are decoded

Status: NEW

(Core :: Layout, defect)

Description

[Seth Fowler [:seth] [:s2h]]

I've seen issues reported many times now where we start an animation or transition that involves an image before the image is decoded. (I'll just say "animation" instead of "animation or transition" from now on.) When this happens, we often don't manage to paint a fully-decoded version of the image until after the animation happens, which looks quite ugly.

Solving this problem for *any* animation is likely infeasible, since we need a list of every frame that may be painted as a result of the animation, and that may be hard to predict with animations that change layout.

That's why I'm proposing that we limit the work in this bug to animations that we can support OMTA for. (And I'm handwaving a bit here, because I'm not sure exactly what we support OMTA for right now.) If we can solve this issue even for just animations that involve translations and opacity, I think we'll greatly decrease the number of people who will encounter this problem.

I don't have a detailed proposal for how we should implement this, but roughly, for OMTA-able animations we might:

- Enumerate all frames that will be painted during the animation.
- Walk the list of frames and ask them to request decoding for any images they need to paint.
- Wait until we've received notifications that we've decoded all of the images before starting the animation.

Comment 1

[Seth Fowler [:seth] [:s2h]]

See bug 1125077 comment 5 for a recent report of this issue.