1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
|
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.
--
Splines are not dashed.
--
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.
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.
--
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.
--
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.
--
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.
--
cairo_show_text is not updating the current point by the string's advance values.
--
Caps are added only to the last subpath in a complex path.
--
ref_counts will go negative if destroy is called with ref_count ==
0. We noticed this in cairo_surface.c but it likely happens in several
places.
--
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?).
--
font-size="0" in an SVG file does very bad things.
--
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).
--
cairo falls over with XFree86 4.2 (probably braindead depth handling
somewhere).
--
The caches abort when asked for a too-large item, (should be possible
to trigger by asking for a giant font, "cairo_scale_font (cr, 2000)"
perhaps). Even if the caches don't want to hold them, we need to be
able to allocate these objects.
|
