Occasionally when stopping or starting the spinner, the entire browser will briefly flash a different color (blue, I think), and then flash back. You can replicate this by creating a spinner in the inspector and calling spinner.spin(document.body) and then spinner.stop() This doesn't happen every time to start or stop the spinner, but it happens frequently enough that you should be able to replicate quickly.
I'm using Chrome 16 and I've heard of people seeing the same thing on recent versions of Safari.
Any ideas what might be doing this?
Sounds like an issue caused by hardware acceleration. You could try to comment out this line and see if it's still flickering. If that helps we can start looking for work-arounds that fix the flashing but continue to use the hardware accelerated renderer.
BTW I did't succeed to reproduce the issue, so maybe its caused by a certain combination/interference with the CSS of the surrounding page? I tried it on the spin.js homepage and on this plain example page with Chrome 16.0.912.63 on OS X.
it's probably related to this chromium bug
@fgnass Yeah, that's the line that's causing it. I think it is related to the bug that @christianhaller is referring to.
The line @fgnass pointed out to crashes Chrome every time for me. Using Fedora 16 with Chrome 15.
After commenting out this line everything works fine. Waiting minified version of spin with this problem fixed natively.
Would making 3d transforms an option passed to the constructor be acceptable?
I think option parameter is a workaround as spinner should better check this automatically.
What would it check for?
Check whether transfrom3d is available on current browser or not. Otherwise, we would always set transform3d to false to make sure end-users won't have browser hang up.
Modernizr can detect this.
If I understand this correctly, it causes problems in browsers that do support 3D transforms, so testing the availability of this feature wouldn't help. I think making it configurable is the best option we currently have. I'm just wondering if we should disable hardware acceleration by default?
+1 for disabling by default. Especially for spin.js web - page: my Chrome hangs up on opening. Happily, I've managed to know this great script before hangings began :) But new users won't appreciate it.
@fgnass i think it probably should be disabled by default for the time being, at least until the bugs are worked out and released in chrome and safari.
Disable 3d transforms by default.
This is in response to discussion on #47.
Has this been fixed yet? I'm still getting a strobe/flash effect on the first usage of a spin.js function (the following usages do not produce it) in Chrome 16.0.912.77 m on Windows 7 SP-1 x64.
As pointed out by fngass, commenting out line 208
seems to hotfix the problem.
Made 3d transforms optional and disabled by default. Closes #47, #41 …
I was seeing this issue too but assumed it was related to my port of spin.js to closure. Your fix works great for me too but I wanted to share a work-around I found which leaves the hardware acceleration intact in case it's helpful. When I create the el in the spin function, I set visibility:hidden. Before I return from that function, I make the element visible again, using a setTimeout with 0 delay. No idea why that works, but it seems to. :)
self.el.style.visibility = 'visible';