Bug 103840

Created attachment 135657 [details]
Image of the result of the program

The line width is supposed to be 0.5 from what I understand.

The problem also only appears to be in the GTK backend as png backends render well.

Systems tested on:
Ubuntu 14.04 and 16.04 64 bit with Intel, Nvidia and AMD accelerators.

Your example code just opens a gray window here, but I guess that is the expected result with a line width of 0.5? I am on Debian testing, so cairo 1.15.8. Did you test with such a new cairo version?

> It appears to have been brought in with 
> 
> 5bc1b1f6aac108d9a3963352ad774bb4fcd69e28 is the first bad commit
> commit 5bc1b1f6aac108d9a3963352ad774bb4fcd69e28
> Author: Chris Wilson <chris@chris-wilson.co.uk>
> Date:   Fri Aug 24 17:22:34 2012 +0100

The above commit is from 2012. You set the Version field of this bug to 1.10.2. That's from 2010. How can a commit introduce a bug into a version that was released two years earlier?

Excellent question: it fails on this

libcairo2:amd64                                                                         1.13.0~20140204-0ubuntu1.1                       amd64                                            The Cairo 2D vector graphics library

> 1.13.0~20140204-0ubuntu1.1 

That's not a cairo version. See e.g. https://www.cairographics.org/news/.
Assuming the above means Ubuntu just took a random git master version, shipped it and never bothered to use a release: The only git commit on that day that I can find is 4144307dbfbe7b297135d9ea4b080cae7e06b997. The changelog and the copyright link on packages.ubuntu.com just 404, so... No idea what Ubuntu might be doing there.

Also, let me ask again: Which cairo version(s) did you try this on? See comment #4:

> Your example code just opens a gray window here, but I guess that is the
> expected result with a line width of 0.5? I am on Debian testing, so cairo
> 1.15.8. Did you test with such a new cairo version?

> Your example code just opens a gray window here

Sorry, my fault. Compiling against Gtk2 does not work for this, it needs Gtk3. Then this becomes reproducable.

I found something. The problem seems to come from `composite_traps` in `cairo-xlib-render-compositor.c`. The X11 protocol uses a 16.16 representation for traps coordinates (32 bit fixed point with 16 bit fractional part). However, the numbers that are passed in are not representable in 16.16 format. There is code for handling that (`line_exceeds_16_16()` and `project_line_x_onto_16_16`), but apparently its precision is not all that great.

This trap is passed in (it's the main part of "what is going on"; there are two other traps generated by `_cairo_traps_tessellate_convex_quad()`, but they are outside of the visible area):

> left from (200000,-0.25) to (-200000,299.75)
> right from (200000,0.25) to (-200000,300.25)
> top=0.25
> bottom=299.75

and this is the computed, supposedly equivalent trap:

> left from (2725.33,0.25) to (-3392,299.75)
> right from (3392,0.25) to (-2725.33,299.75)
> top=0.25
> bottom=299.75

If my math (and my calculator) is not wrong, the left line of the first trap has an "anti-slope" (delta x / delta y) of 400000 while the result's left line has a slope of.... about 20?

@Matthew: Try adding cairo_set_antialias(cr, CAIRO_ANTIALIAS_BEST) to your test case (btw: thanks for the nice test case!) and drawing the line once before and once afterwards (e.g. in red and blue). The results look quite different.

Now we just need someone with the time (sorry, my time for now is up) and knowledge to figure out how to fix `project_line_onto_16_16`.

I can see that the antialias is a valid workaround in c/c++ linking to Cairo directly. On the eclipse side, it doesn't work. 

My solution on the eclipse side was to apply a Cohen Sutherland (Programmatically clip the lines), it works well. It does introduce a performance regression though. I think I will push for my solution on eclipse, as we need to support people with older libs too.

Since it's 16.16, the solution makes sense since clipping it before drawing it clamps it to realistic values.

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/cairo/cairo/issues/289.