Does GSAP offer any solutions to Chrome SVG bugs

[jstafford]

Does GSAP offer any solutions to some of the Chrome SVG bugs, specifically I am getting a jagged line when rotating an svg. This is a documented problem (

Tomorrow, I was getting ready to code up my GSAP solution that is based on a CSS3 transform rotation of the SVG element. I always use Chrome Desktop for development thinking that it is the best browser for everything and it will tell me if something works or not, but Firefox is much better in this animation and does not show jagged lines on the svg element rotation. I know there are hacks for this but I wanted to reach out and ask others if they have run into this and if GSAP offers any help.

 

http://stackoverflow.com/questions/24852879/svg-animation-has-jagged-edges-in-chrome

See the Pen XmKEBp by jstafford (@jstafford) on CodePen

[GreenSock]

Hm, it looks fine in my Chrome (Mac). But since GSAP isn't in charge of rendering, I don't think there's much we can do about rendering glitches like what you're describing. Our hands are tied. Luckily Chrome self-updates pretty often.

[Jonathan]

I tried on both latest mobile Chrome and Chrome desktop on windows 7 (64-bit) and did not see the jaggy lines. But only after a couple of page reloads. Sometimes i see jaggy lines on rotated elements in Firefox but that can be fixed by adding a transparent border or transparent outline. But I believe they fixed that bug.

 

Now webkit based browsers.. they are another beast, and both Google and Apple dev teams take forever to fix bugs, at least the important ones!

 

Sometimes when i get jagged lines or edges on rotated elements in Chrome. You can try adding a border with the same color as the background, along with padding 1px. But with SVG elements a border and padding might not be an option.

 

I usually add -webkit-backface-visibility: hidden ( backfaceVisibility:"hidden" in GSAP) on the rotated element and then that gets rid of it. But again this might not work on rotated SVG elements in webkit.

 

The only bug reports i could see were older bug reports that had to do with transforms in general on elements and images in Chrome, not specific to SVG.

 

You can search for webkit Chrome bugs here: https://code.google.com/p/chromium/issues/list

 

I could not find any new webkit bugs that had to do with rotated SVG jaggy edges in Chrome or Safari.

 

But this is not a GSAP bug. Chrome and Safari are notorious for horrible anti-aliasing for text and transformed elements. So its no surprise that this same webkit bug affects rotated SVG elements as well. 

 

You could always submit a bug report to the Chrome Dev Team, they said that they welcome all bug reports:

 

Bug Reporting Guidelines: https://www.chromium.org/for-testers/bug-reporting-guidelines

 

[jstafford]

Thank you Jack and Jonathan for your responses. It seems Jonathan's suggestion of giving the svg padding (I just stretched the artboard around the actual image so there was a tiny bit of space on all sides) and changing the border color to the fill color that the border contained did the trick. 

 

Glad this is an easy fix. It broke my heart to see this was a problem in Chrome. 

[jstafford]

I just got a 4k monitor at work, and the jagged line problem is still present on this codepen () in Chrome48  (before applying Jonathan's technique, but to a much lesser degree). I have other svg images that I have already done and I am going to try Jonathan's technique again. Anyway, not many people are rocking high resolution screens still. http://www.w3schools.com/browsers/browsers_display.asp

[jstafford]

Maybe I can do a before and after this time in codepens to show the difference in Chrome48, Firefox44, and IE 11.

[Jonathan]

Do the jaggy line show if your SVG is at its largest normal size?

Also you can try adding the attribute shape-rendering="crispEdges" on your SVG child elements to help with jaggy edges.

Allowed values: auto | optimizeSpeed | crispEdges | geometricPrecision

SVG shape-rendering:

https://developer.mozilla.org/en-US/docs/Web/SVG/Attribute/shape-rendering

[jstafford]

http://www.paintcodeapp.com/news/iphone-6-screens-demystified

[jstafford]

thanks for responding Jonathan.  Yes, I am familiar with shape-rendering="crispEdges", but some people avoid it like the plague and recommend shape-rendering="auto" instead . I will get to this sometime early next week and update you on my tests. Right now, I am converting a JSP-Spring4-Hibernate4 app to AngularJS-Spring4-Hibernate4 running on Tomcat application server. Anyway, really excited about using AngularJS view framework with Java-Spring. 

[jstafford]

I incuded the paintcode link above b/c I am a little confused as to why there aren't more high resolution screens with such high use of ios and android mobile devices. Things always look so crisp and clean edged here.

[jstafford]

http://imgur.com/C83GAb2

 

Here is a screenshot of  on my 4k monitor using Chrome48. The "stepstair" or "jagged line" are still present to a much lesser degree before applying Jonathan's technique. I have already proven Jonathan's technique works on a lower resolutions monitor for this image, but haven't corroborated it works on some of my other svg images that are more complicated in terms of path data.

 

Anyway, I have only been using svgs for about 6 months and refining stuff I did a while back.

[jstafford]

I guess my other question is the resolutions of monitors registered at w3 does not distinguish between mobile or desktop, correct? A resolution on a mobile device while lower, may in fact display at a resolution that "looks higher"? Is this correct? 

[Jonathan]

I did notice you are using the same id on each <svg> tag.. #Layer_1. As a rule of thumb an ID is a unique identifier. So you can only have one ID with the same name on a webpage.

 

Also you might what to check the data (d) attribute and original SVG code and make sure its clean. Sometimes SVG can become more crisp if you adjust the points within your data attribute when floating point integers can not scale right. Sometimes whole pixel values work better, and even with one floating point of .5

 

Check this topic out, where Jack made a function to clean the data attribute that have scientific notation in them:

 

http://greensock.com/forums/topic/13688-awful-morphing-due-to-scientific-float-notation/#entry57447

 

Also mobile devices could render differently depending on the display used on the device. Some displays, especially on mobile can render differently due to pixel density. Like if a pixel equals a pixel.. or if a pixel equals 1.5 or 2 pixels, especially when dealing within higher resolution screens. And some of this behavior can also be a browser bug.

 

webkit browsers are really bad at scaling elements. passed a scale factor of 1. Due to rasterizing the element to render on its own layer, even if that element is vector. Me personally i never like the rendering of elements on iPhones, i prefer android. Apple always makes drastic changes to their displays, mostly for the worse. But that is just me and my two cents.

[jstafford]

cool. this is good stuff.

 

in regards to the "I did notice you are using the same id on each <svg> tag"; yes, I know id is a unique identifier compared to class . I don't think I used the id at all as the transform rotation happens on the svg element. Maybe I thought I was going to use it. I also copied that svg element to make that animation. That's why you see id more than once.

 

The css3 transform I did here uses no greensock (I re-did this using greensock, but deleted in codepen for some reason; it was working on my local). I have since made the decision not to delete my codepens any more.

 

 

 

Anyway, I will test out this new advice with my existing images sometime early next week.

[Jonathan]

You can get mixed results when using the same ID on the same element. Either the browser will just use the first instance with that ID. Or the browser will ignore all instances. This is due to the ID attribute sharing the same namespace as the name attribute. So even if your not targeting that ID, its best to have your HTNML markup only use an ID with a unique name.

 

if you have a codepen pro account you can set your codepens to private, instead of public, so only you can see them.

 

Happy Tweening!

[jstafford]

just had a eureka moment and thought I would share.

 

this is why things look so dang good on mobile devices; http://pixeldensitycalculator.com/

 

just calculated my 27 inch ultra high definition monitor (3840 x 2160) and it is 163.18 ppi ; iphone6 is > 400ppi; I am sure the newest Androids are about the same or better ppi than the iphone6 

 

despite their better display in mobile, they are using far inferior resolution on their screens. w3 will not detect this in their browser resolution capturing statistics. Sounds like this might be local data that you need to capture with your visitors (screen size + resolution) . Anyway, I am a newbie and learning this.

[Jonathan]

Also consider that iPhones will rastersize and or downsample the render of elements before being displayed, so that will play a big part on why you might also see blurry elements. And then it also uses webkit in it's main Safari and Google Chrome browser, further making elements more blurry and edges jaggy when rendered.

 

I love SVG's but they don't render the same in each browser, and that is even before you try animating them. Especially if one little point or dimension is off, or whitespace between attributes or in between values, and then all bets are off

[jstafford]

hopefully SVG will render more universal in the browser for the future. I know I have way more control over elements in a vector file format (SVG, etc.) compared to a raster graphics image file format.