<html> <head> <base href="https://bugs.freedesktop.org/"> </head> <body> <div> <a class="bz_bug_link bz_status_NEW " title="NEW - Polygon clipping to surface fails for large coordinate values, limitations of the API not documented." href="https://bugs.freedesktop.org/show_bug.cgi?id=20091#c8">Comment # 8</a> on <a class="bz_bug_link bz_status_NEW " title="NEW - Polygon clipping to surface fails for large coordinate values, limitations of the API not documented." href="https://bugs.freedesktop.org/show_bug.cgi?id=20091">bug 20091</a> from <a class="email" href="mailto:stef_sport_2002@yahoo.it" title="Stefan <stef_sport_2002@yahoo.it>"> Stefan</a> <pre>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.); cairo_stroke(ctx); 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. degree_of_reliance/=10;</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the QA Contact for the bug.</li> </ul> </body> </html>