[cairo] bug in cairo_in_stroke() ?

[Uli Schlachter]

On 27.05.2011 20:43, Soeren Sandmann wrote:
> control H<control.h at gmail.com>  writes:
>
>>> I see unexpected behavior in the cairo_in_stroke() function. Attached
>>> is a simple program showing the problem. It seems the slope makes a
>>> difference. Resizing the window gives different results.
>>>
>>> Is this a bug?
>>>
>>
>> Oh I forgot to tell:
>>
>> cairo version: 1.10.2
>> Gtk version: 2.22.0
>> Glib version: 2.28.0
>>
>> Can people confirm this is a bug in cairo_in_stroke() ?
>
> It certainly looks that way. Here:
>
>     http://www.daimi.au.dk/~sandmann/strok.c
>
> is a version of the test program that works with GTK+ 2.x and therefore
> cairo 1.8. The bug doesn't happen with 1.8, but does happen with git
> master as of some weeks ago.

Hi,

I took a closer look and now I need someone with some more clue to take an even 
closer look. :-)

Attached is the original test case turned into a test case for test/ (for some 
weird reason I prefer looking into problems that way).

Also attached is a "patch" which "fixes" this issue.
cairo_in_stroke() is implemented through _cairo_gstate_in_stroke() which does this:

     limit.p1.x = _cairo_fixed_from_double (x) - 1;
     limit.p1.y = _cairo_fixed_from_double (y) - 1;
     limit.p2.x = limit.p1.x + 2;
     limit.p2.y = limit.p1.y + 2;

Raising the "1" and "2" hides the problem.

I guess this means that there is some rounding issue somewhere that causes this?

Cheers,
Uli

P.S.:
22:13 :) @psytux ~/projects/cairo :(7c499db...)|BISECTING $ git bisect good
f8bb3617c3a7ec598c42eff1f8562e3ccc95127f is the first bad commit
commit f8bb3617c3a7ec598c42eff1f8562e3ccc95127f
Author: Chris Wilson <chris at chris-wilson.co.uk>
Date:   Wed Dec 17 09:32:16 2008 +0000

     Eliminate self-intersecting strokes.

     We refactor the surface fallbacks to convert full strokes and fills to the
     intermediate polygon representation (as opposed to before where we
     returned the trapezoidal representation). This allow greater flexibility
     to choose how then to rasterize the polygon. Where possible we use the
     local spans rasteriser for its increased performance, but still have the
     option to use the tessellator instead (for example, with the current
     Render protocol which does not yet have a polygon image).

     In order to accommodate this, the spans interface is tweaked to accept
     whole polygons instead of a path and the tessellator is tweaked for speed.

     Performance Impact
     ==================

     ...
     Still measuring, expecting some severe regressions.
     ...

-- 
"Do you know that books smell like nutmeg or some spice from a foreign land?"
                                                   -- Faber in Fahrenheit 451
-------------- next part --------------
A non-text attachment was scrubbed...
Name: in_stroke_bug.c
Type: text/x-csrc
Size: 1007 bytes
Desc: not available
URL: <http://lists.cairographics.org/archives/cairo/attachments/20110527/e198d92b/attachment.c>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ugly_hack.patch
Type: text/x-diff
Size: 812 bytes
Desc: not available
URL: <http://lists.cairographics.org/archives/cairo/attachments/20110527/e198d92b/attachment.patch>