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
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
|
cairo_show_surface fails when given a non-default CTM, see the
show_surface.cairo snippet in:
From: Per Bjornsson <perbj@stanford.edu>
To: Cairo mailing list <cairo@cairographics.org>
Date: Wed, 09 Feb 2005 20:05:35 -0800
Message-Id: <1108008335.5349.46.camel@localhost.localdomain>
Subject: [cairo] How is cairo_show_surface supposed to work?
--
cairo_image_surface_create should return a blank image
(eg. transparent black) instead of an image with random data in it.
--
cairo_surface_create_for_image is claiming ownership of the user's data.
--
cairo_font_set_transform should be renamed cairo_font_set_matrix
cairo_font_current_transform should be renamed cairo_font_get_matrix
--
Alexis Georges reports a segfault on AMD64 with a simple program,
(that works in a 32bit chroot).
--
The caches need to have some locking (see: [cairo] Static caches and thread-safety)
--
Scaling of surface patterns is all broken, (try xsvg
gradPatt-pattern-BE-07.svg and zoom in and out).
--
centi_unfinished.svg has big black portions when drawn with svg2png,
(but not when drawn with xsvg).
--
The caches need to be invalidated at font destruction time.
--
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.
|
