Open Bug 960364 Opened 11 years ago Updated 2 years ago

Images flicker / flash when swapped/animated by Javascript in recent versions of Firefox

Categories

(Core :: General, defect)

26 Branch
x86_64
Windows 7
defect

Tracking

()

People

(Reporter: craigw, Unassigned)

Details

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:26.0) Gecko/20100101 Firefox/26.0 (Beta/Release) Build ID: 20131205075310 Steps to reproduce: Please visit this page: http://still-motion-pictures.com/picnic.php In recent versions of Firefox, flickering occurs when the animations are scrolled on and off the screen, or when changing tabs. This behavior is only in these recent versions and other browsers don't show it. These animations are created with javascript by making a image for each frame, laid in the same place and then cycled through by adjusting the visibility css attribute from hidden to visible. In the meantime, can anyone suggest a possible workaround to try out? Actual results: Animations badly flicker, showing the background instead of the image. Expected results: Not flickered.
confirmed on win7+omtc.
slightly better STR is to scroll the window horizontally slowly, and pause such that the window has parts of two imges on screen.
(In reply to craig washburn from comment #0) > In the meantime, can anyone suggest a possible workaround to try out? Place img elements refering to the same files as used in the main image/animations in a fixed position div (somewhere where it won't cause a problem), size them to 1x1, stack them on top of each other, cover them with a div. That should make them be considered visible and we should keep around their decoded image data.
Status: UNCONFIRMED → NEW
Ever confirmed: true
A "full" image visibility update as performed by PresShell::UpdateImageVisibility will build a display list, the display list won't have any items for visibility: hidden imgs, so those will not be in the resultant list of visible images. After we draw each of the images we re-add them to the list of visible images via the OnUnlockedDraw hook. And initially are initial reflow callback on image frames will consider all the images visible (even the visibility: hidden ones because it only looks at the geometry of the image and the relevant scroll frames). Most pages that do a similar thing probably won't trigger the problem as easily because this page has a large amount of decoded image, likely making us go over the limit that we will "willingly" keep around, and this will discard decoded image data more aggressively. Being able to tell the difference between non-visible images in the current tab, and images in other tabs (bug 847221) would probably allow us to be less aggressive with discard non-visible images in he current tab, but would likely only make the problem better, not solve it. If we ignored the visibility style in a "full" image visibility update that would fix this specific case. There are probably other ways of doing image animations like this (using z-index maybe? changing the src attribute?) that might show the same problem. We could hack nsIFrame::IsVisibleForPainting to return true if we are doing image visibility. Or we could switch "full" image visibility updates to just do a full walk of the frame tree looking for "image" frames and calling nsLayoutUtils::UpdateImageVisibilityForFrame on them (so that we never consider the visibility style). This is the direction we want to go anyways as building a display list is overkill for this. If anyone has any other thoughts please share. :)
The logic of marking visibility: hidden images as visible being that visibility: hidden images that are within the viewport are likely to be made visible at some point, otherwise they are rather pointless. The downside being that pages keep around a bunch of hidden images would use more ram for no reason.
Thank you very much for the quick replies on this! It is greatly appreciated and we'll give the possible workaround a try. (In reply to Timothy Nikkel (:tn) from comment #4) > Being able to tell the difference between non-visible images in the current > tab, and images in other tabs (bug 847221) would probably allow us to be > less aggressive with discard non-visible images in he current tab, but would > likely only make the problem better, not solve it. > > If we ignored the visibility style in a "full" image visibility update that > would fix this specific case. There are probably other ways of doing image > animations like this (using z-index maybe? changing the src attribute?) that > might show the same problem. In the first version of this code written in April 2013, we animated by swapping the src attribute and this resulted in flickering when Firefox 20 (I think it was) debuted. Switching from hidden to visible seemed to work ok. We still would see some initial flickering when switching tabs, so we put in a small pause delay when the viewer came back so Firefox could catch up and reload the images.
Update: Using Timothy's suggested workaround we just released a new version of the javascript that doesn't flicker. Since the example page above is public and now has the fix, I have moved the flickering page with its original code to here for future reference: http://still-motion-pictures.com/picnic-flicker-test.php
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.