Bug while drawing certain vertex #38

JakeBr opened this Issue Jan 17, 2014 · 10 comments


None yet

5 participants

JakeBr commented Jan 17, 2014


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.


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.

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

JakeBr commented Jan 17, 2014

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?


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).

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

JakeBr commented Jan 17, 2014

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!


byorgey commented Jan 17, 2014

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.


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


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 commented Jan 17, 2014

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

@byorgey byorgey closed this in 0f5e399 Jan 17, 2014
@byorgey byorgey pushed a commit to diagrams/diagrams-svg that referenced this issue Jan 17, 2014
Brent Yorgey Don't emit last segment of a loop if it is linear
See diagrams/diagrams-cairo#38.  This wasn't actually causing any
observable problems in the SVG backend output, but this seems a
better/more robust way to do things in any case.
byorgey commented Jan 17, 2014

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

@byorgey byorgey reopened this Jan 17, 2014
@byorgey byorgey pushed a commit to diagrams/diagrams-backend-tests that referenced this issue Jan 30, 2014
Brent Yorgey test for diagrams/diagrams-cairo#38 9ea71bb
@bergey bergey added the numeric label Sep 8, 2014
@bergey bergey referenced this issue in diagrams/diagrams-lib Oct 12, 2014

New stuff #218

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment