The following code demonstrates the problem on my OS X 10.5 (using either freshly compiled cairo 1.8.6 or the one that installs from Mac ports)
When the program is ran with input values of 40000000 (40 million) for either of the dimensions, the surface is not filled completely. Instead only a narrow vertical bar is filled. Surface may not be filled at all if origin is moved (see commented code).
This prevents drawing of any polygons that have sufficiently large dimensions, and must be drawn into smaller "tiles" for example.
Created attachment 22876 [details]
Test case showing the problem. Run with parameters 100 40000000 (or 100000000 to be sure :) )
Created attachment 22878 [details]
This is a sample of bad output. Parameters used were: 100 40000000
Also, verified that the bug is not present on Windows (XP, 32 bit)
Created attachment 22882 [details]
Same bug on Windows
I was able to reproduce the same problem on Windows. It only occurs with some large coordinates (see numbers in the example). After example runs, test.png is empty.
If value of Y is selected symmetrically (i.e. -49M and +49M), the surface is properly filled (with red in this case).
Comment on attachment 22882 [details]
Same bug on Windows
int main(int ac, char **av)
double x1, y1;
surf = cairo_image_surface_create(CAIRO_FORMAT_ARGB32, 1000, 500);
cr = cairo_create(surf);
//cairo_surface_set_device_offset(surf, (-1. * x1 / 2.), y1 / 2.);
//cairo_surface_set_device_offset(surf, 1000., 500.);
cairo_move_to(cr, 1000, -49000000);
cairo_line_to(cr, 1000, 40000000);
cairo_line_to(cr, -1000, 40000000);
cairo_line_to(cr, -1000, -49000000);
cairo_set_source_rgb(cr, 1., 0., 0.);
I'm sorry I didn't have my brain switched on while looking at your test case earlier so completely missed the obvious problem: The input coordinates overflow cairo's internal fixed point numbers used to represent polygon geometry, and the resulting overflowed coordinates aren't to be trusted anymore. The current format uses 24 bits to address the pixel and eight bits to address fractions of a pixel, leaving the valid coordinate range in the +-8M range. This is up from the +32k range we had earlier, but obviously not the full double precision range. So this is an expected failure after all. :|
I'm leaving this bug report open as a reminder until we prominently document the input coordinate restrictions and fail in a meaningful way in the face of large numbers.
Is this restriction on the max value for coordinates still in place? I am developing a Gerber viewer and was hoping that I could use the big integer numbers normally associated with Gerber files, without having to do any rescaling. Thanks!
I experience some crap drawing with much smaller numbers when doing..
cairo_move_to (cr, x1, y1 );
cairo_line_to (cr, x2, y2 );
x1=700,457386 y1=478,073704 x2=39032,412069 y2=141,069173
Probably cairo does some internal computation, and maybe some of the values there exceed the limit.
As a workaround, some clipping code before calling cairo_bla should work. But..
I found the same problem, this (undocumented) limitation on the coordinate system severely limits the usability of the library for 'serious projects' like CAD software. In-memory surfaces (like the ones created with cairo_image_surface_create) have limitations on the coordinate system *well* below the claimed (and already limited) 24.8 bit fixed point space.
For example, the following:
cairo_move_to(ctx, -200000., -200000.);
cairo_line_to(ctx, 200000., 200000.);
clearly crossing the clip area will not be displayed.
Since in-memory surfaces are used for double buffering this limits the overall manageable space, even if user coordinates for screen surfaces can go (maybe?) up to +/- 8Mpixels.
It was really frustrating to discover that a 2D api with double precision coordinates is internally restricted to 20.something bits.
-- 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/252.