New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Occasionally causes a strobe effect in Chrome and Safari #47

Closed
JustinTulloss opened this Issue Dec 16, 2011 · 13 comments

Comments

Projects
None yet
6 participants
@JustinTulloss

JustinTulloss commented Dec 16, 2011

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?

@fgnass

This comment has been minimized.

Show comment
Hide comment
@fgnass

fgnass Dec 16, 2011

Owner

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.

Owner

fgnass commented Dec 16, 2011

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.

@christianhaller

This comment has been minimized.

Show comment
Hide comment
@christianhaller

christianhaller commented Dec 16, 2011

it's probably related to this chromium bug
http://code.google.com/p/chromium/issues/detail?id=77126

@JustinTulloss

This comment has been minimized.

Show comment
Hide comment
@JustinTulloss

JustinTulloss Dec 21, 2011

@fgnass Yeah, that's the line that's causing it. I think it is related to the bug that @christianhaller is referring to.

JustinTulloss commented Dec 21, 2011

@fgnass Yeah, that's the line that's causing it. I think it is related to the bug that @christianhaller is referring to.

@vkovalskiy

This comment has been minimized.

Show comment
Hide comment
@vkovalskiy

vkovalskiy Dec 27, 2011

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.

vkovalskiy commented Dec 27, 2011

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.

@JustinTulloss

This comment has been minimized.

Show comment
Hide comment
@JustinTulloss

JustinTulloss Dec 27, 2011

Would making 3d transforms an option passed to the constructor be acceptable?

JustinTulloss commented Dec 27, 2011

Would making 3d transforms an option passed to the constructor be acceptable?

@vkovalskiy

This comment has been minimized.

Show comment
Hide comment
@vkovalskiy

vkovalskiy Dec 28, 2011

I think option parameter is a workaround as spinner should better check this automatically.

vkovalskiy commented Dec 28, 2011

I think option parameter is a workaround as spinner should better check this automatically.

@JustinTulloss

This comment has been minimized.

Show comment
Hide comment
@JustinTulloss

JustinTulloss Dec 28, 2011

What would it check for?

JustinTulloss commented Dec 28, 2011

What would it check for?

@vkovalskiy

This comment has been minimized.

Show comment
Hide comment
@vkovalskiy

vkovalskiy Dec 28, 2011

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.

vkovalskiy commented Dec 28, 2011

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.

@fgnass

This comment has been minimized.

Show comment
Hide comment
@fgnass

fgnass Dec 28, 2011

Owner

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?

Owner

fgnass commented Dec 28, 2011

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?

@vkovalskiy

This comment has been minimized.

Show comment
Hide comment
@vkovalskiy

vkovalskiy Dec 29, 2011

+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.

vkovalskiy commented Dec 29, 2011

+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.

@JustinTulloss

This comment has been minimized.

Show comment
Hide comment
@JustinTulloss

JustinTulloss Dec 29, 2011

@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.

JustinTulloss commented Dec 29, 2011

@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.

JustinTulloss added a commit to JustinTulloss/spin.js that referenced this issue Dec 29, 2011

Disable 3d transforms by default.
This is in response to discussion on #47.
@techouse

This comment has been minimized.

Show comment
Hide comment
@techouse

techouse Jan 29, 2012

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

transform: 'translate3d(0,0,0)',

seems to hotfix the problem.

techouse commented Jan 29, 2012

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

transform: 'translate3d(0,0,0)',

seems to hotfix the problem.

@fgnass fgnass closed this in 16cc1cb Jan 30, 2012

@plutrono

This comment has been minimized.

Show comment
Hide comment
@plutrono

plutrono Feb 3, 2012

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. :)
setTimeout(function() {
self.el.style.visibility = 'visible';
},0);

plutrono commented Feb 3, 2012

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. :)
setTimeout(function() {
self.el.style.visibility = 'visible';
},0);

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment