1156762 - image flickering due to rapidly updating background-image

Status: RESOLVED INCOMPLETE

(Core :: Graphics: ImageLib, defect)

Description

[Alice0775 White]

[Tracking Requested - why for this release]: regression.

Reported on http://forums.mozillazine.org/viewtopic.php?p=14127569#p14127569

The image flickering on https://www.asus.com/Networking/RTAC87U/overview/ (above "Unbeatable Hardware" section)

Actual Results:
The "animation" is flickering.

See video of the flickering:
http://gfycat.com/GaseousLastingDinosaur
https://gfycat.com/BountifulNiceHectorsdolphin

Expected Results:
The "animation" should be done by loading around 200 PNGs in succession on the same position.


Pushlog:
https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=53d0b45c24c5&tochange=daf8243cd190

Regressed by: Bug 1079627

Comment 1

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

I can reproduce this, yeah.

This page is repeatedly updating the background-image property.

I am a bit suspicious that these images used to be small enough to be sync decoded under the old rules, and now are decoded asynchronously.

If that's true, I don't think we want to go back to sync decoding these images. We probably need to instead be careful not to invalidate until the new decode is complete.

Comment 2

[Lawrence Mandel [:lmandel] (use needinfo)]

Tracking this regression. It's getting late in Beta to take a change so it's possible that this will not be fixed in 38.

Seth - Looks like you're taking this one so I've assigned it to you.

Comment 3

[Elbart]

(In reply to Seth Fowler [:seth] from comment #1)

> I am a bit suspicious that these images used to be small enough to be sync
> decoded under the old rules, and now are decoded asynchronously.

FWIW, I had to go back as far as Firefox 8.0a1 for a version which plays this animation without flicker or delayed/slow start.

Last good revision: a627b24e684e (2011-07-28)
First bad revision: cef1817c3b13 (2011-07-29)
Pushlog:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=a627b24e684e&tochange=cef1817c3b13

Comment 4

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

(In reply to Elbart from comment #3)
> FWIW, I had to go back as far as Firefox 8.0a1 for a version which plays
> this animation without flicker or delayed/slow start.

Wow! It sounds like we've had issues with this for a very long time. Thanks for investigating this, Elbart!

Lawrence, should we reconsider tracking given that this isn't a recent regression?

Comment 5

[Sylvestre Ledru [:Sylvestre]]

esr31 is marked as unaffected. Alice, did you check ESR 31?

Comment 6

[Alice0775 White]

the regression window of comment#0 is correct.

However, I can reproduce on 31esr release build, so, this should be different problem.

Comment 7

[Alice0775 White]

That flickering was fixed in the past once.
Fixed range
https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=d1903414198f&tochange=02d3440cd34b

Fixed by Bug 1089046 in Nightly36.0a1 cycle.


And, broken again in Nightly38.0a1 and Aurora37.0a2 cycle by Bug 1079627.

Comment 8

[Sylvestre Ledru [:Sylvestre]]

Seth, if you think you can come with a patch, we would take it. Thanks!

Comment 9

[Elbart]

(In reply to Seth Fowler [:seth] from comment #4)
> (In reply to Elbart from comment #3)
> > FWIW, I had to go back as far as Firefox 8.0a1 for a version which plays
> > this animation without flicker or delayed/slow start.
> 
> Wow! It sounds like we've had issues with this for a very long time. Thanks
> for investigating this, Elbart!

I may have been too strict, as I've only watched out for how long it takes for the animation to start. General connection-speed may have influenced the test.

When only checking for flickering, this is the regression-range I came up with:

Last good revision: 22288130fea2 (2012-08-14)
First bad revision: 7d4268f8884c (2012-08-15)
Pushlog:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=22288130fea2&tochange=7d4268f8884c

http://hg.mozilla.org/mozilla-central/pushloghtml?changeset=a0bddf5fcb91

That's 17.0a1-territory, and I guess the culprit for the flicker is in that changeset.
Maybe
> adf31747cf5e	Kyle Huey — Bug 683290: Discard images that are not in the DOM. r=bz

(In reply to Alice0775 White from comment #6)
> the regression window of comment#0 is correct.

http://elbart.bplaced.net/image_flicker/nightly_20150116_-_before_bug_1079627.mp4

This is the Nightly before bug 1079627 landed.

(In reply to Alice0775 White from comment #7)
> That flickering was fixed in the past once.
> Fixed range
> https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=d1903414198f&tochange=02d3440cd34b
> 
> Fixed by Bug 1089046 in Nightly36.0a1 cycle.

http://elbart.bplaced.net/image_flicker/nightly_20141116_-_after_bug_1089046.mp4

This is the Nightly after bug 1089046 landed.

PS: My machines aren't exactly the fastest ones, maybe that's the reason why I have the flickers in older versions where Alice0775 White does not.

Comment 10

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

(In reply to Elbart from comment #9)
> PS: My machines aren't exactly the fastest ones, maybe that's the reason why
> I have the flickers in older versions where Alice0775 White does not.

That makes sense to me. I suspect that whether the flickering happens comes down to whether we can decode the new frame fast enough before a repaint happens.

Elbart, Alice0775 White, I really appreciate your effort in finding a regression range for this bug. Having a regression range always makes things _much_ easier to fix.

(In reply to Sylvestre Ledru [:sylvestre] from comment #8)
> Seth, if you think you can come with a patch, we would take it. Thanks!

I'm just trying to prioritize things, since there are a lot of things that need fixing right now. If we view this as a recent regression and track it, we're giving it a really high priority, so I wanted to double-check whether we still feel that way given the more recent regression range information.

Comment 11

[Jet Villegas (inactive)]

(In reply to Alice0775 White from comment #0)

> Expected Results:
> The "animation" should be done by loading around 200 PNGs in succession on
> the same position.

That's really not a good way to author the desired effect. :-/

That said, it seems there are 2 issues contributing to the visual "flickering" here. The delay caused by image decoding latency is also visible in other browsers on the first loop through the animation. We could fix that in Firefox by reverting to eager decoding, but I'd rather not optimize for these cases as the memory hit is significant.

The visual flicker after the first loop (when the images are surely decoded) isn't reproducible in other browsers and is an invalidation issue in Firefox. I'd really like to fix that one, since it may affect other cases of image animation, but it isn't a recent regression. 

Can we decouple the image decoding from the painting bug, and fix the latter? I don't think that's a Release Blocker though.

Comment 12

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

I filed bug 1158440 about the flickering issue.

Comment 13

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

Sorry, I mean the flickering issue that occurs after we finishing image decoding. The flickering during image decoding is a separate matter (see Jet's comment 11).

Comment 14

[Lawrence Mandel [:lmandel] (use needinfo)]

(In reply to Seth Fowler [:seth] from comment #4)
> Lawrence, should we reconsider tracking given that this isn't a recent
> regression?

Yes. Given that we've shipped this issue for such a long time, it clearly doesn't block our release. I'm dropped tracking. We can let this ride the trains or, as Sylvestre said in comment 8, if you come up with a safe patch, we can consider an uplift.

Comment 16

[Mike Taylor [:miketaylr]]

(updating title to make this easier to find)

Comment 17

[Jet Villegas (inactive)]

(In reply to Lawrence Mandel [:lmandel] (use needinfo) from comment #14)
> if you come up with a safe patch, we can consider an uplift.

The fix for bug 1273455 should help this one too. If others can confirm, I'll push for the uplift.

Comment 18

[Mike Taylor [:miketaylr]]

Attachment: bg-primed-cache.mp4

Using the URL from Bug 1273546, you can see there are some improvements in Nightly.

When the images are already cached, there's no flickering. With an empty cache, they flicker until they're all downloaded. In < 50, they just flicker all the time.

Comment 19

[Mike Taylor [:miketaylr]]

Attachment: bg-empty-cache.mp4

Comment 20

[stepand76]

What is the status of this bug? Is there a chance to be fixed soon? I just encountered it. I need to update 40 of images frequently. They are loaded and put in the DOM but Firefox flickers.

Comment 21

[Jet Villegas (inactive)]

(In reply to stepand76 from comment #20)
> What is the status of this bug? Is there a chance to be fixed soon? I just
> encountered it. I need to update 40 of images frequently. They are loaded
> and put in the DOM but Firefox flickers.

This should be improved in Firefox 50 (Beta.) Please test and report back.

Comment 22

[Alice0775 White]

The web page is no longer available.