Scaling SVG with Greensock blurry in IE

[brendynz]

Does anyone know why when animating the scale of an svg, it gets blurry in IE, and only looks clear in Chrome and Safari once the animation has finished?

 

In this quick test (http://www.brendyn.com/test/) the top image is SVG and the bottom is a PNG. If looked at in IE, once it gets big, you can see it's very blurry, which an SVG shouldnt be. The PNG is only slightly blurry (which is expected). 

 

I assume it's a core browser difference, but I would have assumed TweenLite would have taken care of that. Can anyone offer any insight?

 

Thanks very much in advance.

[ohem]

I don't know about IE, but force3D:false always fixes that problem in webkit browsers.  

 

Another option is setting the size of the SVG to it's largest size, and doing a "from" tween from a smaller size, instead of bringing it in small & doing a "to" tween to the large size.

[GreenSock]

That's a browser rendering thing, yeah. The browser is trying to optimize performance by essentially taking a picture of the element at 100% size, then animating that picture so that the GPU can push the pixels really fast (GPUs are awesome at just applying transforms on raster images). Without that optimization, the browser has to re-rasterize the vectors on every render (60 times per second) which keeps it nice and sharp, but is costly from a performance standpoint. 

 

Rendering vectors is just inherently an expensive process. It's basically fabricating all the pixels on-the-fly. Using a raster image proxy of sorts (taking that picture) can significantly improve performance but if you're only doing relatively simple vectors and the area of change isn't huge and you're on decent hardware, you'll probably never notice a difference. 

 

By default, GSAP uses 3D matrix values for transforms because it triggers the browser to get the GPU involved (better speed), but the tradeoff as you're seeing here is that it does that rasterization. Setting force3D:false tells GSAP not to force-apply 3D matrix values, thus the browser probably doesn't get the GPU involved (that's really up to the browser) and it keeps things sharper (but slower). 

 

I hope that helps clear things up. 

[brendynz]

I added force3D:false into the code (http://www.brendyn.com/test/), and it seemed to help with Safari and Chrome, but IE is still blurry. Am I adding it into the wrong place?

 

TweenLite.to(_item, 1, {force3D:false, scale:5, delay:0});

[GreenSock]

That's the right spot. Unfortunately this isn't really something that GSAP controls - it's totally a browser thing. So IE may still say "I don't care what you do - I want to prioritize performance so I'm gonna layerize/rasterize this element on the GPU..." I don't know of a way to force IE to outlaw the GPU's involvement there. But like Ohem suggested, if you build your objects so that they start out at the biggest size you'll ever need them (thus the rasterized version is adequately high-resolution), you'd probably get the benefit of GPU involvement AND it'd still look sharp when at its largest size (which would be 100%). 

[OSUblake]

I'm not seeing any blurriness in IE, but I can't really see the entire thing. And what element are you scaling? Without changing force3D, notice the difference in Chrome between scaling an actual SVG element and scaling an element inside an SVG. It alternates between the two...

See the Pen 3e2171f16dad6dee12da8fe032a96bcf by osublake (@osublake) on CodePen

[brendynz]

@Greensock - My confusion was that TweenLite is advertised as to take care of all the browser differences back until IE9 in most cases so that the dev doesn't need to worry about it. But in this case, that doesnt seem to be the case. Is that correct? Ive tried starting off large and then scaling after that, and that seems to work in IE11, but not 9 or 10. 

 

To confirm, Tweenlite actually doesnt handle SVG scaling browser differences as it does with other features?

[OSUblake]

If there is a blurriness issue, there's really nothing GSAP can do. But like I said, "IF". The CodePen I linked to in my previous post shows what can cause blurriness, but that only happens in Chrome/webkit. I did not see any blurriness in IE. Can you provide a CodePen that shows the issue? It's hard to tell what's going on when you link to stuff on your stuff server. And how are you testing IE 9/10? Native, VM, emulation?

 

Also note that Microsoft is ending support for IE 9/10 in a couple weeks.

[brendynz]

This is what I see with the code pen link in IE:

http://brendyn.com/test/temp.html

 

But I seem to have gotten one working here:

http://brendyn.com/test/

(http://codepen.io/leisurelarry/post/svg-scale-test)

Note how when it scales up, it doesnt get blurry.

 

Defining it huge before setting it small as originally suggested in the post. 

A shame that can't be a feature in TweenMax to do that behind the scenes. 

[OSUblake]

Well that's gotta be a first... creating a CodePen as a blog post. I guess I should have provided this link which shows how to create a pen.
http://greensock.com/forums/topic/9002-read-this-first-how-to-create-a-codepen-demo/
 
But it's ok. I went ahead and made a working version for you.
 
First off. That image doesn't look like IE. And the animation in that pen has 2 tweens, one will be blurry, the other won't.

var tl = new TimelineMax({ repeat: -1 })
  .to("svg", 2, { scale: 4, repeat: 1, yoyo: true }) // BLURRY
  .to("g", 2, { scale: 4, repeat: 1, yoyo: true }) // NOT BLURRY

Second, your issue really has nothing to do with SVG because you are not directly tweening one. Look at the difference between tweening a background image and the SVG.

 

Full screen...

See the Pen 9bc31659bfffb8877113c04fd44354b7 by osublake (@osublake) on CodePen

 

And here's the code. You can change the layout of the windows by clicking on the change view button in the top-right and then choosing an editor layout.

See the Pen 9bc31659bfffb8877113c04fd44354b7?editors=001 by osublake (@osublake) on CodePen

[GreenSock]

@brendynz, I'm really sorry to hear you felt mislead regarding GSAP's cross-browser capabilities. We try very, very hard to solve all the problems we can but unfortunately we just can't control every aspect of browsers and their various quirks/inconsistencies. For example, trying to make 3D transforms work in IE6 is pretty much impossible because of the technical limitations of the browser itself. But we've done a ton of work to make 2D transforms work there. We do what we can.

 

We don't advertise anywhere that GSAP solves all cross-browser issues, but please let us know if there's something we've promoted on our site that isn't entirely true and we'll definitely address it. We don't want to mislead anyone, that's for sure. 

 

If you look around at all the other libraries out there, I don't think you'll find any that even come close to what GSAP does for solving cross-browser issues. So we feel confident in saying that it's a strength of GSAP's, but it's not a silver bullet. 

 

As for your suggestion to have GSAP automatically do the upscaling internally, it sounds good in theory but there are several liabilities that make it a somewhat dangerous endeavor. We built GSAP to cater to the top-end animators out there who do some pretty advanced stuff, yet we also tried to make it beginner-friendly. Part of our philosophy about how a tool like GSAP should work is that it doesn't over-reach in ways that could cause problems for advanced developers. So, for example, we don't want to just assume that changing the native size of an element won't have negative consequences for the user's other code. If we solely focus on our own little scale tween, it may seem perfectly reasonable but what if the user has other code that depends on that element's native size being a certain value? What if they have conditional logic that our little switcheroo might mess up? 

 

So if GSAP was intended to just be a black box that handles every aspect of rendering your graphics, that approach might be fine. But we try to stay out of the developer's way as much as possible and allow a ton of flexibility. Users can trust that GSAP isn't going to overreach its bounds. It only touches what they ask it to touch. 

 

Remember a while back when several libraries added methods directly at the prototype level and hijacked native objects/methods/properties? It was a mess. If you happened to load that library (or someone else loaded that library) on the page, native objects suddenly acted very differently and it was difficult to troubleshoot and work around. We never want to do stuff like that. To that library's author, it seemed perfectly reasonable given the use case he had in mind. But he didn't think far enough ahead (in my opinion) and how his choices might negatively affect developers down the road. Again, we don't want to make that mistake.

 

We'll keep doing our best to solve cross-browser issues as much as we can. And feel free to make specific suggestions when you identify things that we could improve upon. The goal is to make GSAP the defacto standard for animating things on the web because it "just works" where so many other options fail. Again, I'm sorry GSAP seems to have let you down here, but from what I can tell it's not really something GSAP can solve for you anyway.