2004-08-02 11:51:57 +00:00
|
|
|
cairo_clip is really slow, (with at least the Xlib and image
|
|
|
|
|
backends). An accelerated implementation of the IN operator would
|
|
|
|
|
probably help a lot here.
|
2004-05-11 06:52:19 +00:00
|
|
|
|
|
|
|
|
--
|
|
|
|
|
|
2003-09-12 10:53:03 +00:00
|
|
|
Splines are not dashed.
|
|
|
|
|
|
2004-03-30 17:24:29 +00:00
|
|
|
--
|
|
|
|
|
|
2003-09-12 10:53:03 +00:00
|
|
|
The polygon tessellation routine has problems. It appears that the
|
|
|
|
|
following paper has the right answers:
|
|
|
|
|
|
|
|
|
|
http://cm.bell-labs.com/cm/cs/doc/93/2-27.ps.gz
|
|
|
|
|
|
|
|
|
|
[Hobby93c] John D. Hobby, Practical Segment Intersection with
|
|
|
|
|
Finite Precision Output, Computation Geometry Theory and
|
|
|
|
|
Applications, 13(4), 1999.
|
|
|
|
|
|
2004-07-01 13:38:23 +00:00
|
|
|
Recent improvements to make the intersection code more robust (using
|
|
|
|
|
128-bit arithmetic where needed), have exposed some of the weakness in
|
|
|
|
|
the current tessellation implementation. So, for now, filling some
|
|
|
|
|
polygons will cause "leaking" until we implement Hobby's algorithm.
|
|
|
|
|
|
2004-03-30 17:24:29 +00:00
|
|
|
--
|
|
|
|
|
|
2003-10-15 12:26:51 +00:00
|
|
|
Stroking a self-intersecting path generates the wrong answer, (in
|
|
|
|
|
mostly subtle ways). The fix is to tessellate a giant polygon for the
|
|
|
|
|
entire stroke outline rather than incrementally generating trapezoids.
|
2003-09-12 10:53:03 +00:00
|
|
|
|
2004-03-30 17:24:29 +00:00
|
|
|
--
|
|
|
|
|
|
2004-03-22 17:56:35 +00:00
|
|
|
Cairo is crashing Xnest with the following message:
|
|
|
|
|
|
|
|
|
|
X Error of failed request: BadMatch (invalid parameter attributes)
|
|
|
|
|
Major opcode of failed request: 72 (X_PutImage)
|
|
|
|
|
Serial number of failed request: 28
|
|
|
|
|
Current serial number in output stream: 29
|
|
|
|
|
|
|
|
|
|
confirmed on a quite default install of debian unstable.
|
2003-07-18 11:34:19 +00:00
|
|
|
|
2004-03-30 17:24:29 +00:00
|
|
|
--
|
|
|
|
|
|
|
|
|
|
cairo_scale_font modifies objects that the user expects to not change. For example:
|
|
|
|
|
|
|
|
|
|
cairo_font_t *font;
|
|
|
|
|
|
|
|
|
|
cairo_select_font (cr, "fixed", 0, 0);
|
|
|
|
|
font = cairo_current_font (cr);
|
|
|
|
|
cairo_scale_font (cr, 10);
|
|
|
|
|
cairo_show_text (cr, "all is good");
|
|
|
|
|
cairo_set_font (cr, font);
|
|
|
|
|
cairo_scale_font (cr, 10);
|
|
|
|
|
cairo_show_text (cr, "WAY TOO BIG!!);
|
|
|
|
|
|
|
|
|
|
We could fix this by not storing the scale in the font object. Or
|
|
|
|
|
maybe we could just force the size to its default after set_font. Need
|
|
|
|
|
to think about this in more detail.
|
|
|
|
|
|
|
|
|
|
--
|
|
|
|
|
|
2004-04-02 08:01:09 +00:00
|
|
|
cairo_show_text is not updating the current point by the string's advance values.
|
|
|
|
|
|
|
|
|
|
--
|
|
|
|
|
|
2004-03-30 17:24:29 +00:00
|
|
|
Caps are added only to the last subpath in a complex path.
|
2004-04-16 08:33:20 +00:00
|
|
|
|
|
|
|
|
--
|
|
|
|
|
|
|
|
|
|
ref_counts will go negative if destroy is called with ref_count ==
|
2004-04-29 07:26:53 +00:00
|
|
|
0. We noticed this in cairo_surface.c but it likely happens in several
|
2004-04-16 08:33:20 +00:00
|
|
|
places.
|
2004-04-29 07:26:53 +00:00
|
|
|
|
|
|
|
|
--
|
|
|
|
|
|
|
|
|
|
Patterns are broken in various ways. The SVG test case demonstrates
|
|
|
|
|
some regressions, so something has changed in cairo. Also,
|
|
|
|
|
transformation plus repeat doesn't work in either Xrender or
|
|
|
|
|
libpixman, (nor in glitz?).
|
2004-05-04 09:25:54 +00:00
|
|
|
|
|
|
|
|
--
|
|
|
|
|
|
|
|
|
|
font-size="0" in an SVG file does very bad things.
|
2004-10-26 14:38:43 +00:00
|
|
|
|
|
|
|
|
--
|
|
|
|
|
|
|
|
|
|
move_to_show_surface (see cairo/test):
|
|
|
|
|
|
|
|
|
|
* 2004-10-25 Carl Worth <cworth@cworth.org>
|
|
|
|
|
*
|
|
|
|
|
* It looks like cairo_show_surface has no effect if it follows a
|
|
|
|
|
* call to cairo_move_to to any coordinate other than 0,0. A little
|
|
|
|
|
* bit of poking around suggests this isn't a regression, (at least
|
|
|
|
|
* not since the last pixman snapshot).
|
2004-11-11 12:15:12 +00:00
|
|
|
|
|
|
|
|
--
|
|
|
|
|
|
|
|
|
|
cairo falls over with XFree86 4.2 (probably braindead depth handling
|
|
|
|
|
somewhere).
|