Large animations are displayed with delay after changing the tabs

NEW
Unassigned

Status

()

Core
ImageLib
P3
normal
4 months ago
a month ago

People

(Reporter: roxana.leitan@softvision.ro [PTO from 08-04-2017 until 08-21-2017], Unassigned)

Tracking

55 Branch
Points:
---

Firefox Tracking Flags

(firefox55 affected)

Details

(Whiteboard: [gfx-noted], URL)

Attachments

(1 attachment)

Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:55.0) Gecko/20100101 Firefox/55.0
Build ID: 20170419030223

[Affected versions]:
Nightly 55.0a1

[Affected platforms]:
All platforms: Windows 10, Mac OS X 10.12

[Steps to reproduce]:
1.Launch Nightly 55.0a1 with a new profile
2.Navigate to https://lh5.googleusercontent.com/-mvpIxrtlkAA/Tndmi1sf6zI/AAAAAAAAD1E/I2vwpRqn1z8/s500/FlyEarth500_Micael_Reynaud.gif
3.Open a new tab
4.Open a new window and navigate to about:memory
5.Click "Minimize memory usage" button
6.Go to the tab with the animation (opened at step 2)

[Expected result]:
The animation should be displayed without delay

[Actual result]:
The animation is displayed with delay
If the tab with the animated gif is not active, minimize memory usage is going to get rid of the decoded images from the cache.  When you want to see it again, you'll have to re-decode.  I don't know if network does anything with the network cache with minimize memory, but I wouldn't be surprised; in that case, you'd have to download the image again.

If you do a mozregression on this, did it get worse within the last two weeks?  I'd expect it if the time spent is in decoding.
Flags: needinfo?(roxana.leitan)
Whiteboard: [gfx-noted]
This is the intended behaviour for animated images that aren't decoded after bug 686905. This is the same thing that happens when we switch to a tab where we have a large undecoded non-animated image: we will draw the page without the image, or with only part of the image decoded. Because we can now discard animated images this now happens for animated images.

Animated images, even when they are not decoded still have a virtual clock that tells us what frame to draw if the image were visible at that time. (The refresh driver handles this, so we don't have timers running constantly for gifs in background tabs etc.) So when we draw an animated image in this situation there is a correct frame to draw and it is not usually the first frame. It might be possible to reset the animation clock when we re-decode an image, but that could also introduce more bugs: the original reason why discarding of animated images was turned off was because of an issue like this in bug 414259.

So under the assumption that we can't just start drawing the first frame of the image, we might have to decode a very long gif which could take _seconds_ even on a bleeding edge brand new desktop. Blocking painting for seconds is not an option, so we need to paint something until we have the correct frame to show to the user. If we just display the frames of the animation as we decode them on the way to the destination frame it looks like a weird fast-forward effect. I tried this and it was very non-pleasing. So we are left with drawing nothing until we can draw the correct thing.

As we get more feedback on this change we can evaluate if this is a large annoying issue, then we can look into resetting the animation clock. But for now I think the current behaviour is the best approach.
Flags: needinfo?(roxana.leitan)
Created attachment 8868531 [details]
Recording #37.mp4

Please see attached a screencast with this bug.

Timothy, since this is the intended behavior, should this bug be closed?
Flags: needinfo?(tnikkel)
I'm leaving it open to gauge if we get enough feedback on this issue to consider use a different strategy in this case (ie the last paragraph of comment 2).
Flags: needinfo?(tnikkel)
Panos, we could use some UX evaluation on this particular issue - who could we talk to?
Flags: needinfo?(past)
I would suggest Philipp, as this seems related to perceived performance of Firefox.
Flags: needinfo?(past) → needinfo?(philipp)
From the information in this bug, it sounds like the performance gain we get by suspending gifs is worth the delay when switching to a tab with large gifs (since gifs are often secondary or decorational content).

It would be interesting to see what this looks like on gif-heavy pages like Slack, which can become an absolute crawl when lots of gifs are playing at the same time.
Related (but probably orthogonal): have we ever thought about putting gifs into their own thread to make gif-heavy sites more responsive?
Flags: needinfo?(philipp) → needinfo?(milan)
Good question - decoding is already done in separate threads. Painting them in a separate thread, or treating them as media/video is a subject of other bugs (there is a push to deal with animated images as "video", rather than special casing them as we do today.)
Flags: needinfo?(milan)
Priority: -- → P3
You need to log in before you can comment on or make changes to this bug.