Closed Bug 1527085 Opened 11 months ago Closed 11 months ago

weather model animation doesn't repaint

Categories

(Core :: Graphics: WebRender, defect, P3)

defect

Tracking

()

RESOLVED FIXED
mozilla67
Tracking Status
firefox-esr60 --- unaffected
firefox65 --- unaffected
firefox66 --- disabled
firefox67 --- fixed

People

(Reporter: dbaron, Assigned: aosmond)

References

(Blocks 1 open bug, )

Details

(Keywords: regression)

Attachments

(2 files)

When I have WebRender enabled, the weather model animation at
https://www.tropicaltidbits.com/analysis/models/?model=gfs-ens&region=us&pkg=apcpn24&runtime=2019021112&fh=24
doesn't repaint correctly -- I just see one or two ticks of the animation and then the image just stays static, instead of seeing the entire animation run smoothly.

I'm running on Linux (64-bit) with Intel graphics, and I have force-enabled both OpenGL and WebRender.

In more detail:

Steps to reproduce:

  1. if needed, go to about:config and toggle:
    layers.acceleration.force-enabled -> true
    gfx.webrender.enabled -> true
    and restart Firefox. (This is needed for me.)
  2. load https://www.tropicaltidbits.com/analysis/models/?model=gfs-ens&region=us&pkg=apcpn24&runtime=2019021112&fh=24
  3. click the Play button above the map (the [>] button between the [<-] and [->] buttons).

Expected results:
the images smoothly change (at least once they're all loaded, which might be an issue over a slow network)

Actual results:
mostly, the images don't change, except if I move the mouse over the image and keep moving it (which causes a tooltip to repaint on top of the images)

If I flip the gfx.webrender.enabled pref back to false (its default), then I no longer see the bug.

I can repro on macOS. Seems to repaint while the mouse is moving or we are triggering other repaints somehow. But if I stop moving the mouse then a lot of the animation frames get skipped.

Actually, the link:
https://www.tropicaltidbits.com/analysis/models/?model=gfs-ens&region=us&pkg=apcpn24&fh=24
may be better in that it may keep working longer in the future. (The initial link I gave has a date in it... and I'm not sure how far in the future today's forecast images will be available.

Priority: -- → P3

This doesn't seem to repro for me (also on Linux x64 + Intel gfx).

One piece of information that would be useful to know is whether the bug still reproduces if you disable 'gfx.webrender.picture-caching' (a restart is required between changing that pref).

You can verify if picture caching is on/off by toggling 'gfx.webrender.debug.picture-caching' (no restart required) - the tile invalidation debug overlay will only appear when picture caching is enabled.

(In reply to Glenn Watson [:gw] from comment #4)

(answering the questions in reverse order)

You can verify if picture caching is on/off by toggling 'gfx.webrender.debug.picture-caching' (no restart required) - the tile invalidation debug overlay will only appear when picture caching is enabled.

If I toggle this to true, I see lots of green and red tiles with red text in the upper left of the green ones. Toggling it to true also makes the bug go away for the remainder of the session (even if I reload the page and press play again).

One piece of information that would be useful to know is whether the bug still reproduces if you disable 'gfx.webrender.picture-caching' (a restart is required between changing that pref).

If I toggle this to false and restart, I still see the bug.

(In reply to David Baron :dbaron: 🏴󠁵󠁳󠁣󠁡󠁿 ⌚UTC-8 (if account gets disabled due to email bounces, ask a bugzilla admin to reenable it) from comment #5)

You can verify if picture caching is on/off by toggling 'gfx.webrender.debug.picture-caching' (no restart required) - the tile invalidation debug overlay will only appear when picture caching is enabled.

If I toggle this to true, I see lots of green and red tiles with red text in the upper left of the green ones. Toggling it to true also makes the bug go away for the remainder of the session (even if I reload the page and press play again).

And to clarify, I mean that toggling it to true and then back to false again makes the bug go away for the remainder of the session.

... although it might actually be that certain types of switching between windows or something like that makes the bug go away until I restart the browser.

Assignee: nobody → aosmond

I believe I can reproduce on Linux consistently. If I move my mouse at all after hitting play, it animates, but if I avoid that, it stays still.

mozregression points me at:

https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=5b1c54cbac38c0be22e4f8441710629d620807a1&tochange=096cd49afd334998208b46af3bbfc32d1ebd0760

which I suspected, although my attempts at fixing it thus far have failed. I know nsImageFrame::mImage has changed, so we cannot rely upon the cached image container, but I am somewhat confused why ignoring that cache did not fix the issue. Investigation continues.

Blocks: 1520158
Keywords: regression

When the underlying image request (imgIRequest) changes for an image, we
need to ensure that we invalidate the cached WebRenderImageData such that
the image container stored therein is updated to be for the correct
image. This gets a little tricky because some display items store both
the current and previous images, and choose to display the latter if the
former is not yet ready. We also don't know what image the image
container belongs to. As such, we now compare the producer ID of the
current frame in the image container, to the expected producer ID of the
current image request. If they don't match, we must regenerate the
display list.

Pushed by aosmond@gmail.com:
https://hg.mozilla.org/integration/mozilla-inbound/rev/43678f936e37
Ensure we invalidate when the image request changes. r=jrmuizel
Status: NEW → RESOLVED
Closed: 11 months ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla67
QA Whiteboard: [qa-67b-p2]
You need to log in before you can comment on or make changes to this bug.