Firefox rendering bug

[abullen]

I have been running up against a rendering bug in FF.

 

I am using DrawSVG & TimelineMax to do an animated line drawing and FF (ver. 39.0.3) displays random points in this animation prematurely. The animation works fine in Safari & Chrome. 

 

I'm not sure how to solve this one. Any suggestions would be appreciated.

 

Here is an image of the problem with red arrows pointing to some of the random spots.

 

A.

[Carl]

Hi and welcome to the GreenSock forums,

 

Not sure what the issue is from looking at the image alone.

 

Can you please put just enough of your SVG and js code in this pen so that we can see it for ourselves?

 

http://codepen.io/anon/pen/waOBPm

 

Hit fork, add your svg and js, save, send us the link. 

 

Also what version of FireFox? if its not the latest, please try updating it.

 

Thanks!

 

 

-

 

if you are new to CodePen, check out these tips: http://greensock.com/forums/topic/9002-read-this-first-how-to-create-a-codepen-demo/

[abullen]

The version of FF is 39.0.3 - the latest.

 

Here is pen you request:

 

See the Pen qdvdVV by abullen (@abullen) on CodePen

 

In Safari & Chrome it renders correctly. In FF, it is "spotty" from the start.

[Jonathan]

Just to ask for additional info..

 

is this on Firefox on Windows or Firefox on Apple Device.. i presume an Apple device since you mentioned Safari?

[Jonathan]

It looks like you need to add immediateRender:false since you are using a fromTo() tween, which by default from() tweens have  immediateRender set to true.

 

See the Pen aOMOYy by jonathan (@jonathan) on CodePen

tl.fromTo("#Radius", 1 , 
   {immediateRender:false, drawSVG:"0%", autoAlpha:1},
   {drawSVG:"100%"} 
)

...

NOTE: by default, immediateRender is true in fromTo() tweens, meaning that they immediately render their starting state regardless of any delay that is specified. This is done for convenience because it is often the preferred behavior when setting things up on the screen to animate into place, but you can override this behavior by passing immediateRender:false in the fromVars or toVars parameter so that it will wait to render the starting values until the tween actually begins.

 

Does that help?

 

Resource:

fromTo() http://greensock.com/docs/#/HTML5/GSAP/TimelineMax/fromTo/

[abullen]

 

Does that help?

 

 

 

Yes, the FF rendering problem goes away with that change (at least on the Mac). Thank you!

 

However, this was actually a looping animation and adding this immediateRender parameter has stopped the resetting (i.e. canvas clearing) with each new loop.

 

Nothing I seem to change in this code (i.e. adding .remove()  etc. ) seems to reset the canvas after each loop is finished. Is there some magic method or syntax that can achieve this?

[Jonathan]

immediateRender: false fixes that behavior in Windows Firefox as well. It's not really a Firefox bug. It's just because the immediateRender properties default is true for from() tweens:

 

from()

fromTo()

staggerFrom()

staggerFromTo()

 

Also when you say nothing seems to reset the canvas, do you mean you want to restart the timeline from the beginning or clear all values. The reason I ask is to just clarify since I notice your using SVG, not canvas.

 

Any additional information will be greatly appreciated, thanks!

[abullen]

Also when you say nothing seems to reset the canvas, do you mean you want to restart the timeline from the beginning or clear all values. The reason I ask is to just clarify since I notice your using SVG, not canvas.

 

Any additional information will be greatly appreciated, thanks!

 

 

Yes, I want to clear the existing lines drawn by the timeline and start over with a blank screen at the beginning of the next loop.

[Carl]

Hi Abullen,

 

Thanks for the demo, much better than the image. In the future please try to minimize your svg and js as much as possible to make it easier to find the issue.

Unfortunately my anatomy is not the fresh and its very difficult to associate the ids in the svg with the code.

 

 

Jonathan,

 

Thanks for tackling this! although changing immediateRender might help when and how autoAlpha is being applied, i think the issue is more related to how FireFox renders the strokes with drawSVG:"0%"

 

 

Check out this simplified version which just uses set() with no animation (use FireFox)

 

http://codepen.io/anon/pen/dorYeB?editors=001 (correct link now)

 

You will see 4 black dots and a red line.

 

Go to the JS code and change the line that has "20%" to "0%"

Run the pen again. 

Notice how that red line is totally gone? no dot?

 

The question remains. Why does that 1 path render properly and not the others?

 

Will need to look into it further.

[Jonathan]

I see it now Carl, I stand corrected

[Carl]

upon further investigation this appears related to how FF renders some strokes that have a stroke-linecap defined when the stroke-dashoffset and stroke-dasharray are equal. 

 

 

Here is my reduced pen "fixed" (no animation, just setting drawSVG:"0%"

http://codepen.io/anon/pen/dorYeB?editors=011

 

and yours

http://codepen.io/anon/pen/pJYKez?editors=001

 

Not entirely sure what we can do in DrawSVGPlugin to accommodate this at the moment.

 

If you need stroke-linecap:round perhaps you can set it to none in your css and set it to round in your fromTo tweens like:

http://codepen.io/anon/pen/KpEeXP?editors=011

[Jonathan]

Good find Carl

[OSUblake]

I think I experienced the same thing with my SVG plant generator, but it happened in Chrome too. I didn't spend much time investigating the problem, and instead just set the opacity to 0 until it was time to start. The onStart callback sets the opacity to 1. Here's what it looks like without the fix. 

 

Uncomment line 92 to fix it.

 

See the Pen 98c34a69bd1115e08ceb09f6ce9a325c by osublake (@osublake) on CodePen

[Carl]

Blake, Thanks for chiming in and for the clear demo. 

 

FWIW Jack and I have been discussing internally setting opacity:0 or visibility:hidden if drawSVG:0, sort of like autoAlpha for svg strokes. 

However, we really really don't like throwing new properties into the mix behind the scenes as it opens up the door for conflicts with other code that folks have.

We're going to experiment with some things. If we have any news, will post back here. 

[GreenSock]

I think I may have found a solution - would you mind trying this preview in codepen? 

https://s3-us-west-2.amazonaws.com/s.cdpn.io/16327/DrawSVGPlugin.js (only usable on codepen)

 

I already dropped it into Carl's and it seemed to work well. And I didn't need to mess with opacity or some other property.

[OSUblake]

It still shows up in mine 

See the Pen 7501ff2719487fb8f55df188123c2f7b by osublake (@osublake) on CodePen

[GreenSock]

Ah yes, thanks for the demo. Should be fixed now. Please take a peek (might need to clear your cache). 

[OSUblake]

Cool. What was the problem?

[GreenSock]

Just some sort of odd drawing artifact in the browser. Not much logic to it quite frankly. It showed up at every point along your line even though the dash was way longer. So to solve it, I just made the dasharray "0px 99999px" when it's supposed to not show at all. Seems to work fine. Agreed?