Bug: Android Chrome Scaling Issue <1.0 Edge Case

[MattyBalaam]

This is an edge case definitely, but making an element which zooms from a small size (in this case 0) up to 1, will appear very blurred until the animation is complete. Both Android Browser and Firefox are fine.

I assume this is related to hardware-scaling optimisations and potentially there may be nothing Velocity can do, but I have created a reduced example: http://codepen.io/MattyBalaam/pen/ewdvt

Device: Nexus 10 Android: 4.4.2 Browser: Android Chrome 34.0.1847.114

[MattyBalaam]

I have also added a GSAP based animation to the same page which does not exhibit this behaviour, instead rendering crisply.

[julianshapiro]

@MattyBalaam

You are awesome. I love you so much for helping me find edge cases like these.

I have been able to replicate this issue. I will be looking into it today, and will report back.

[kokarn]

I can at least confirm it is also does the same on Sony Z1 with chrome browser and default rom.

[julianshapiro]

Thanks, @kokarn :)

[julianshapiro]

This fixes it: http://codepen.io/julianshapiro/pen/rpmcA

All I did was reverse [ 1, 0 ] to [ 0, 1 ]. The reason for the blurring and reason why my fix works:

http://stackoverflow.com/questions/10417890/css3-animations-with-transform-causes-blurred-elements-on-webkit/10417962#10417962

The question is whether I do anything about this or not. I'll be looking into it today.

[julianshapiro]

I know a clever way to fix this. I should be able to implement this by tonight.

[MattyBalaam]

Ah, excellent. Amazed at how much you are getting done.

[julianshapiro]

If you keep helping me find bugs, I'll make sure I keep fixing them :)

[julianshapiro]

@MattyBalaam

Please test the latest version and confirm the problem has been fixed. Thank you!

[MattyBalaam]

I can confirm this is now fixed on the Nexus 10.

A little extra even more niche edge case now - I noticed I am also getting a similar blur issue on IE9, but only in the case of using SVG graphics (in my case a background image, I have not tested other SVG uses). Manually adding in an initial scale of 1 with a duration of 1, in addition I also appeared to need an opacity of 0.01 - a value of 0 would not trigger intiial SVG rendering - fixed my issue. Might there be a way of manually forcing the implemented fix?

[julianshapiro]

I know I'm asking a lot of you at this point, but if you can be kind enough to put together a pen for this issue, I will find the time to look into this.

[MattyBalaam]

As I say very edge case, and is actually IE9s fault, but I have put this together anyway.

http://cdpn.io/CExrd

When the fixed and unfixed versions run at the same time often either the unfixed one fixes itself, or the fixed one breaks I have found - I am guessing this is related to when the images have loaded and are initially rendered. In my case the images have already loaded so I do not see this issue.

[julianshapiro]

Thank you so much. I can confirm the issue on IE9.

I will look into a fix today.

[julianshapiro]

1) To get IE9 to reliably display an SVG background, you need to first ensure that you have a properly structured HTML page, including DOCTYPE declaration, etc. That fixed the problem for me.

2) To solve the bluriness issue, you need to ensure the image has loaded first; inserting a 250ms delay before the Velocity call solved bluriness for me.

3) Neither of the scale/opacity tricks you were employing are necessary.

As for why GSAP doesn't need a delay, it appears as if their tween actually fires later than Velocity due to GSAP's overhead and therefore doesn't actually start running until the SVG has had time to load. Velocity is quicker off the ground and therefore does runs into this race issue.

That's what it looks like, at least. Accordingly, I don't know that I could possibly implement any sort of fix for this. But if I'm wrong/missing something, would love to know.

Thanks again, Matty.