Miter Join fails on "closepath" in Google Chrome.

[SmartArtsStudio]

The following in-lined SVG path works in Chrome, FireFox, IE (svg tags removed github strips svg code) directly from in-lined HTML page:

path id="A_inner_stroke_red" fill="none" stroke="#FF0E00" stroke-width="5.0233" stroke-linejoin="miter" stroke-miterlimit="10" d="M374.639,119.635 362.166,87.396 349.541,119.635z"/

However feed it into vivus and ONLY in Chrome:

The stroke-linejoin = "miter" fails on the "closepath" vertex. It treats the close/start vertex like a "manually" closed subpath (eg instead of closing with 'z' behaviour, it acts like 'lineto' fist vertex 374.639,119.635 behaviour,) applying the ‘stroke-linecap’ value instead?

FireFox, IE vivus.js performs properly.

[maxwellito]

Hi there,
I'm sorry I keep trying to reproduce your bug but without success. The SVG behave the same in Chrome and Firefox. I'm probably missing something.
Can you please provide me examples (from jsFiddle, or any other platform)? Thanks :)

[SmartArtsStudio]

Hello,
Have a look at the following jsfiddle, in chrome look carefully at the the three center triangles, each has a rounded line cap at its Z vertex instead of a miter join? (current workaround for chrome: appended (overlapped) first and second vertices where a closing Z should work )

https://jsfiddle.net/qajtL81z/3/

Thank you.

[maxwellito]

Hello again,
I'm really sorry but I still don't see the difference between Chrome and Firefox rendering. And also the link with Vivus.

Firefox v44.0.2 on Mac OS X Yosemite

Chrome v48.0.2564.116 (64-bit) on Mac OS X Yosemite

[SmartArtsStudio]

Wow you are right both of your screen shots do render the same, which surprises me even more because the BOTH render the same BUG not just chrome. Because they are identical the failing "linejoin=mitre" is probably not as obvious you as it is to me (jsfiddle renders it much smaller than directly in the browser - so zoom the jsFiddle render in and it will be much clearer.)

If you focus on the three center triangles, ignore the outside strokes of the 'A'...

On the white internal triangle only the top vertex (which is the start and close vertex) is rounded not 'miter'ed (sharp point) like its other two which are sharp points.You can see the black background showing through at this vertex between the white and red sharply pointed vertex, their should be no black background showing at this vertex just like its other two sharp pointed vertices which are white flush up against the red.

Then on the red triangle it is the bottom left vertex (start & close) that is rounded, black background showing through before the grey sharply pointed vertex. And on the grey triangle it is the bottom left vertex (start & close) which is rounded not a sharp point the other two are sharp points showing through between there what should be a white point

What is causing them to be rounded instead of a sharply pointed 'miter' join. Is despite the drawing command notation specifying close path via 'z' which SVG/browser should read as a join... what the SVG is reading is a separate line start, and a separate line end, which just happen to overlap at the same coordinates.

Because they are just line ends SVG/browse is applying the 'stroke-linecap' values set to 'round' at each end of a line, because because they happen to overlap each other it looks like a nicely rounded vertex.

When SVG/browser reads it as a path close 'z' all three vertices are considered joins and the path has no line start or line finish, to add caps to.

The Bodymovin.js library I tried animating this with originally had a very SIMILAR (but different) problem. But that was because his internal parser was missing the code which appended the the 'z' to the path string. Based on your screen shots initially I would have assumed vivus was missing the same thing internally, but for the fact on my Windows 7 OS ...Firefox and IE render the jsFiddle as they should all sharp pointed vertices.

I initially I thought possibly because Pathformer.prototype.polygonToPath is the only method that explicitly appends a newElement.d += 'Z'; Because I manually converted my < polygon >'s to < paths > perhaps paths were not fed through this method and somewhere else in the code it was accidentally having its 'z' left off. But if that were the case all three browsers would render the same rounded bug.

Bodymovin.js renders the closed joins property in firefox and chrome (set to ''svg' and 'html' properly. 'canvas' doesnt render any miter joins, but I think that is to do with Canvase seemingly incomplete implementation of SVG and is why am focusing on HTML< svg >. Bodymovin.js's render engine code is also much larger, also its render source code (custom json format not svg) adds way more overhead than needed for simple path animations).

So I know chrome can render 'z' closed path joins... The fact your screenshots showed me firefox on Mac does not, while firefox on windows does IS a head scratcher?? Because I though despite the different operating systems I though the browser render engines themselves were identical on all platforms... but I am far from an expert on browser implementations.

But I am pretty sure because firefox and chrome on Mac CAN clearly render SOME miter joins, they must know how to do the 'z' closed path joins as well.

Like I mentioned I can work around it by over lapping the path on itself extended one more vertex beyond the actual close path vertex. But the bug is there, now you can see it in the screenshots on mac as well.

Sorry to be so long winded I was just hoping the extra info may be of some help finding it :)
Thanks for your time looking into this.
Daniel

[SmartArtsStudio]

OH Drop the javascript code altogether and render the same 'A' SVG static HTML straight, and you will see the source renders all the rounded vertices properly as sharp points... so it is being modified by vivus internally.

[SmartArtsStudio]

Read the previous two emails on github, I had some SVG tags in the response which git hub stripped out, I edit updated them so they remained in the response and it actually makes some sense :)

[SmartArtsStudio]

OK I have updated the jsFiddle to include SVG animated by vivus, AND the SVG static HTML... zoom in, all will be be revealed, probably should have lead with this :) https://jsfiddle.net/qajtL81z/8/

[SmartArtsStudio]

OK I have updated the jsFiddle to include SVG animated by vivus, AND the SVG static HTML... zoom in, all will be be revealed, probably should have lead with this :) https://jsfiddle.net/qajtL81z/8/

[maxwellito]

Ok, I guessed the problem you're talking about. There's always a gap at the end of animations, which looks like a glitch because the stroke is never complete. The only solution is to add the option selfDestroy: true which remove every useless SVG attributes when the animation is over. But make the Vivus instance dead, because you can no longer rewind, play, reset...

Please check https://github.com/maxwellito/vivus#option-list

[SmartArtsStudio]

Aaaaaah... ofcoarse!!! Thankyou... so the 'bug' was actually in my assumption!!! Thanks for finding it! :)

...I was really stumped by it, because I was pretty sure I understood all the vivus code and it looked just fine. I don't know what is going on in firefox and IE on windows 7... it seems chrome is actually the only one rendering as vivus untended! Perhaps the others are falling back onto the original SVG after the animation completes for some reason, or looping.

Sorry to send you on a wild goose chase, I do really appreciate your help though, thank you very much again.
Daniel.

[maxwellito]

You're welcome. I guess you also spent a lot of time to write me your answers :)