Bug while drawing certain vertex

[JakeBr]

import Diagrams.Backend.Cairo.CmdLine
import Diagrams.Prelude

main :: IO ()
main = defaultMain dia

dia :: Diagram B R2
dia = triangle 1   # fc green # rotateBy (1/5)
   <> square   1.2 # fc white # lw 0

If you use this code with a width of 400 and produce a png, there's a small black line next to the rightmost vertex that should not be there. That also happens with different rotations, but only with that vertex (see this gif).

I tried it with the Cairo and the SVG backend; with the SVG backend, it looked fine.

[fryguybob]

I can reproduce this on Windows with what I think is Cairo 1.10.2. What OS and Cairo version were you using? Cairo's SVG output looks correct. My guess is that we are emitting both a start and end point for the path (that due to numerical wibbles don't quite match) and then we call C.closePath. These numerical wibbles turn in to Cairo rasterizing a tiny segment that it cannot accurately perform intersections with which maxes out the miter limit. With Cairo SVG, it clips the numbers (only six digits passed the decimal point show in the SVG) and the end points are equal.

[jeffreyrosenbluth]

I can reproduce this bug on OSX 10.8.5, Cairo 1.16 as well.

[JakeBr]

I'm using Ubuntu 13.04 and what looks like Cairo 1.12.14.

Producing an SVG image with the Cairo backend actually has the same bugged result for me. I don't know if that's what you meant?

[fryguybob]

I just checked and I think triangle here eventually ends up calling polyRegularTrail which is defined in terms of polyPolarTrail. This leaves plenty of room for numeric wibbles. A couple of options for fixing:

• Change polyPolarTrail so that given equal rotations modulo a full turn it always gives equal points. This has the downside of still relying on an equality test on doubles.
• Change the Cairo backend to emit the same (in bit representation) start and end point for loops, or don't emit the last segment if it is straight while still calling C.closePath (I think those do the same thing).

[fryguybob]

@JakeBr This is interesting, can you upload the SVG produced by Cairo somewhere?

[JakeBr]

I guess uploading svg files to github is a bit awkward, but it should work if you copy the text into a local file and rename it to be a .svg file. Unless someone knows of a better place to upload them.

edit: thanks!

http://htmlpreview.github.io/?https://github.com/JakeBr/JakesDiagramsGIFs/blob/master/bug2.svg

[byorgey]

It looks to me like triangle calls polySidesTrail, not polyRegularTrail. In any case, I don't think numeric wibbles in those functions are to blame: they generate loops (via closeTrail) which do not store a duplicated start and end point. However, I think you might be right about us generating slightly different start and end points followed by a call to C.closePath when actually drawing with cairo: see here: https://github.com/diagrams/diagrams-cairo/blob/master/src/Diagrams/Backend/Cairo/Internal.hs#L297 We call withLine which performs cutLoop before drawing the segments, and then call closePath if it was a loop. We ought to special-case loop drawing a bit earlier in the pipeline. I'm guessing we probably do something similar with the SVG backend.

[fryguybob]

@JakeBr There is a trick to doing that using http://htmlpreview.github.io/:

http://htmlpreview.github.io/?https://github.com/JakeBr/JakesDiagramsGIFs/blob/master/bug2.svg

Anyway, this renders fine for me in Chrome, but you can see in the SVG code that the start and end values are different, with (0.429059, -0.38632) for the start and (0.429047, -0.38632). My output from Cairo has them the same as (0.429059 ,-0.38632). Go figure. Anyway, I think there are some ways for us to avoid this.

[byorgey]

I think I was able to fix this. Patch coming soon.

[byorgey]

Reopening this, since there may be a bit more we want to fix (though the original problem is solved). See the comment thread here: 0f5e399#commitcomment-5102368