Reel blinking in Firefox

[lifeinlightspeed]

I've been testing reel for various 360 reels and set up a bunch of them in the past month for a project.

They were all working wonderfully but sometime in the past couple weeks they started blinking in Firefox once the reel loads and the spins begin (I'm running FF v.21). This same problem isn't persisting in IE or Chrome.

Example: http://s3.amazonaws.com/LLShop/reel/SABRINA-S-B-BIG.html

Any assistance would be appreciated - thank you...!

[pisi]

Have crappy connection at the moment, but from a brief look, I would say the images are far too big for Firefox to render them in time. Hence the blinking. I can not even load them all.. Will do some measurements once my connection is back in shape.

[lifeinlightspeed]

Hello!

Just following up on this. We've had this problem only in Firefox but no other browsers, so it seems like it must be specifically related to how Firefox is loading either (or both) the script and images vs. Chrome, IE, etc.

Today I added a 6 second delay to see if it would help give more time for the images to load, but it still flickers: http://s3.amazonaws.com/LLShop/reel/CLASSIC-O-O-BIG.html

I realize that one is large. Here is a much smaller version of the same reel, each file is about 1/10th of the size. The flicker still occurs:

http://s3.amazonaws.com/LLShop/reel/CLASSIC-O-O.html

I absolutely love this script. Any help would be appreciated, thanks!

[lifeinlightspeed]

I'm still at a loss on this - any help would be appreciated ~ thanks!

[pisi]

Just a short one (no time :( ) I toy with it for a while now and I still have no clear idea what might be causing this, but I noticed few things:

• When looking on the network tab in Firebug, I see there a LOT of repeated requests, which pop out during the animation. Many of which time out, which is fairly natural considering the pace the images actually change (only memory cache is able to keep up with the demand).
• You load resources from //s3.amazon..., so the URLs are protocol-less. If I am not mistaken local cache is disabled for secure connections and since this URL can be used in both secure and insecure environment, it as a result doesn't appear to be cached at all. Use http://s3.amazon... to give cache a chance.
• Also in my Firefox on about:config page I had both cache control options (browser.cache.disk.enable and browser.cache.memory.enable disabled (supposedly I user choice, but I don't remember setting it so..). When enabled, both the flicker and the repetitive requests stop. I guess this might somehow be related with Firebug (?).

[lifeinlightspeed]

Thanks!

Thanks Petr,

I just did some testing to see if changing any of the above would help.

1. Repeated Requests - I'm not sure how I can respond to this to test and see if there's a workaround, or if its a cause. It only happens in Firefox as far as I can tell, so it's something unique to how the browser is rendering this stuff.

2. //s3.amazon.com resource loading - I added http:// to these URLs but it doesn't seem to have any affect. I'm still seeing the flickers.

http://s3.amazonaws.com/LLShop/reel/CLASSIC-O-O-BIG.html
http://s3.amazonaws.com/LLShop/reel/CLASSIC-O-O.html

3. I'm using Firebug too and I regularly flush out my Disk/RAM Cache using a Firefox Extension called Cache Status. Both of the cache control options (browser.cache.disk.enable and browser.cache.memory.enable) were enabled for me.

Still seeing flickers. :(

[pisi]

From what I can tell Firefox renderer simply can not keep up with the tempo and partial aborts with added queueing is the result. When I for example let it run and flicker for a while, I wasn't then even able to log anything into console unless I stopped the Reel animation. Even though the renderer was still clearly heavily queued, the stop happened instantly leading me to believe, that it is not Javascript choking and queueing, but the renderer itself. Which is a good thing I think.

You see, your BIG images really are far too huge for poor Firefox's slice of CPU power to draw them in time. So let's try to employ the GPU instead. I patched the code to enable hardware acceleration on the image in Firefox and so far it looks good even with //s3.ama... without the http:. Must say I can not get the smaller image to flicker, but the big one flickered reliably and this made it to stop.

Please try using this jquery.reel.js to see if it helps. Fingers crossed.

[lifeinlightspeed]

Thank you Petr,

I've changed the reel to the one in your link above on the following two examples (linked again here to make it easy).

http://s3.amazonaws.com/LLShop/reel/CLASSIC-O-O-BIG.html
http://s3.amazonaws.com/LLShop/reel/CLASSIC-O-O.html

Sadly, it seems to have helped the smaller version a little but hasn't gotten rid of the flickering.

[lifeinlightspeed]

P.S. - I'm reloading it a bunch right now and it ONLY seems to be doing the flickering on the first spin. After that it's working perfectly. After that, it's loading fine.

Also, using this script version seems to make the script working entirely in IE and Chrome for me.

[lifeinlightspeed]

Just following up on this issue. Thanks!

[kzurawel]

Same here, our reels are not nearly as large as @lifeinlightspeed is using but we still get the flicker in Firefox as well.

[pisi]

Sadly, this issue seems to be a combination of several different factors, which makes it hard to spot a common ground. @kzurawel Can you show me your Reel(s)?

[kzurawel]

@pisi Sure, here is one of them:

http://www.nissancommercialvehicles.com/nv-cargo/gallery

It only seems to have flickering issues in Firefox (both Mac and Windows).

[pisi]

Since the hardware acceleration had some positive outcome, I guess there's no harm in merging that into the development branch and into the next release.

Sadly, I still have no clear clue about the blinking :/

[MartinPluta]

We are using HD images and experience the same (in that case even stronger) effect. Fix is much appreciated, although I know, that this one is probably rather to be solved by mozilla. Best regards

[pisi]

From the above linked #231. New observations from testing in Firefox (23.0.1 on OSX 10.6.8):

When I am testing just loading & rendering time of an image in your dimensions with no Reel, no HTML nor Javascript, I am getting combined times of up to 89 ms for PNG with alpha, up to 43 ms for PNG without alpha channel. With default tempo: 36 there's 27 ms window to load, which means that Firefox is not able to load such images in time.

I did the same test with JPG and the same dimensions loaded in no more than 21 ms on 100% quality and no more than 3 ms on 80% quality.

So my general suggestion in these image dimensions would be to use JPGs with 80% or less compression quality.

[MartinPluta]

Thanks for the quick reply and the suggestions. Since these images are supposed to be in such a high resolution for a scientific project, we cannot reduce the image quality. Once the project is published, I may provide a URL here. We will just use it as it is and wait for technical improvements of FireFox.

[MartinPluta]

Alright. There is a solution to this issue. At least it did work out with the previously mentioned reel. This reel displays a sequence of 100 images, each with dimensions of 1920px height and 1080 px width.

Realizing that FireFox is able to display the images properly when debugging with the 'Inspector Tool' via right click and 'Inspect Element', I assumed that FireFox has the capability to display high resolution images within the reel and therefore I did append

.reel-cached {
  display: block !important;
}

to the css declarations. This overrides the default display: none style, being applied by the reel. For our scenario of application, the reel is now running with optimal performance.

If this solution is confirmed by others, it is maybe worth setting the display style for reels running in FireFox accordingly by default or providing an additional option to allow developers to choose whether they prefer the 'preloaded' images to be set visible or invisible.

With best regards

Martin

[MartinPluta]

The images are visible then and you may position them somewhere outside of the window area with some additional css declarations. FireFox will keep them loaded and display them without any flashing.

.reel-cached {
  display: block !important;
  position: fixed;
  bottom: -10000px;
}

[pisi]

Yes, this makes the preloaded images visible. This approach is indeed interesting, because in the next version, these cached images won't be present in the DOM anymore and will instead become pure in-memory-only Image instances. But seeing this I may have to revert this and do offscreen instead of invisible like you do.

I'm thrilled to see somebody confirm this.

@MartinPluta, can you please try the soon to be released 1.3 RC over there in the development branch - this doesn't have these cached DOM nodes. I'm really curious whether this will make some difference for you. Thanks!

[MartinPluta]

Sure, I will try to do this throughout the weekend and drop a comment here as soon as I have some results. Thanks for the link to the development branch.

Best regards

Martin

[lifeinlightspeed]

Interesting; I'll try this as well and report back with what happens.

On Fri, Sep 27, 2013 at 7:48 AM, Martin Pluta notifications@github.comwrote:

Sure, I will try to do that throughout the weekend and drop a comment here
as soon as I have some results. Thanks for the link to the development
branch.

Best regards

Martin

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/196#issuecomment-25250382
.

J. Adam Lefever

Twitter http://www.twitter.com/adamlefever -
Facebookhttp://www.facebook.com/people/Adam-Lefever/612622497-
LinkedIn http://www.linkedin.com/in/therealadamlefever -
MarketMisfithttp://www.marketmisfit.com-

Adamlefever.com http://www.adamlefever.com

"...the man who really counts in the world is the doer, not the mere
critic -
the man who actually does the work, even if roughly and imperfectly,
not the man who only talks or writes about how it ought to be done."

• Teddy Roosevelt (1891)

[MartinPluta]

The current development version produces the same issue, which could not be solved with any additional CSS declaration. Possibly, you find another solution or some working CSS declaration. Before making any plans for changes in the development, I recommend that you perform further testing.

If there s any way I can support you, just let me know.

Best regards

Martin

[harshavarma]

I tried both the edge version of reel and reel 1.2. I too can confirm the css solution no longer works on the edge version. The image flickering issue started with Firefox 21 and it is also present in Firefox Aurora (v 26).

[pisi]

That's what I thought, but the memory only image caching was worth a shot ;) Sadly it looks like renderer needs to cache these, so I put the cache container back in the DOM with visible images shifted out of sight far up left inspired by the workaround by @MartinPluta. Guys, please test out the reborn gh-196-firefox-flicker branch for me please. Fingers crossed.

I'd very much like to hide these images if possible - render them visible inside, but inside a hidden container - so I backed in an option to test this too. Please test this with cache_hide: true option. Thank you!

[MartinPluta]

Thanks for the effort. I will give it a try on the weekend I guess. Meanwhile, I was working to get the reel running with www.leapmotion.com . Think this will probably be in some notebooks in the near future and its worth to check it out. As soon as I have managed to get it running with gesture control (it already runs somehow but requires some improvements), I will let you know.

I'll give some feedback on the firefox branch by next week.

[pisi]

That's super awesome! I'm thrilled to see Leap to make it into production. Can't wait.

Thank you, Martin.

[pisi]

I managed to put together an example using images and options from nissancommercialvehicles link here in the thread. This link does flicker for me in Firefox 24 on OSX, so I was off exploring solutions. Will put the example and updated code online later today, but here's what I tried and saw:

1. I don't want these cached images to weigh the whole element down by being inside. I want them outside, but loading into memory only was enough for the browser's cache, but not much for the renderer, which is what led to the issue in question - didn't work out.
2. So I reverted back to having the nodes in the DOM and shifted off screen which also allowed to next the cache in <body> directly - did work and makes the renderer happy to stop flickering!.
3. I was also able to reduce the cache image dimensions to some artificially small number in an effort to mitigate footprint of the hangover - did work too :).
4. But as soon as you hide the images or their container, they are out of the renderer and need to be reprocessed again, which induces the flicker - didn't work out.

So points 2 and 3 combined looks like our solution, folks!

[pisi]

OK, so here's jsfiddle to reproduce the flickering. During the 1 second opening animation and also during the initial phases of hand dragging, it does flicker in the bottom are of the images right where the wheels and shadow are. The flickering goes away after a little while as renderer caches these images.

And here's an updated fiddle with flickering cured. Now the code pre-caches images for renderer, which ceases the flicker.

Whoever can, visit these links with Firefox and verify the results for me please.

[pisi]

Folks, a form of the CSS workaround has been implemented and will land in next release. I believe it will help :) If you'd like to test it out with your flickering setup, pick the development version.

[pisi]

Dear friends, I have a great faith in the recently released v1.3rc that it will resolve this lengthy Firefox issue. Can someone please try it out and verify so that I can bump it? Thanks!

[pisi]

Released today as part of v1.3.0

[harshavarma]

I tested the latest release and can still see the flickering issue in Firefox. The images are high-res (1920x1080). Can the previously mentioned css fix be applied as a workaround for now?

[lifeinlightspeed]

I am still having the flicker issue as well. There was a period of time that the flicker had stopped, but it seems to be more difficult to resolve than previously thought.

[pzane-kbsp]

The problem exists when FF's hardware acceleration is enabled, which is by default. Not sure if there is a way around it programmatically.