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
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
|
API Shakeup planning
--------------------
Patch submitted to mailing list?
/ Documentation included in patch?
|/ Review of patch completed?
||/ Test case included?
|||/ Committed.
||||/
New functionality (more-or-less)
--------------------------------
cairo_begin_group, cairo_end_group, cairo_get_group
cairo_<device>_surface_mark_dirty
Consistent error handling for all objects
Somewhat backwards-compatible changes
-----------------------------------
PDRTC user data (was Re: [cairo] Patch improving fallbacks)
PDRTC setters and getters
PDRTC cairo_output_stream_t and cairo_surface_finish()
PDRTC cairo_current_path -> cairo_copy_path_data
PDR C cairo_surface_finish, cairo_surface_flush
PDRTC Abbreviation hunt: cairo_init_clip and cairo_concat_matrix
PDRTC Renaming the terms of the rendering equation
PDRTC default matrix
PDRTC cairo_paint
PDRTC Making set_source consistent
PDRTC cairo_stroke_path -> cairo_stroke_to_path
PDRTC cairo_current_matrix
PDRTC cairo_mask
PDRTC cairo_fill_preserve, cairo_stroke_preserve, cairo_clip_preserve
PDR C A hidden offset for the xlib backend
Backwards incompatible
----------------------
PDRTC Simplifying the operator set
PDRTC cairo_create and eliminating cairo_set_target_surface
PDRTC Eliminating cairo_copy
PDRTC Eliminating cairo_surface_set_repeat/matrix/filter
PDRTC Eliminating cairo_show_surface
* Add support for non-antialiased rendering. API ?
* Clean up the cache code a bit, (there is at least one redundant
level of cacheing, and there are some minor style issues).
* Add CAIRO_FILL_RULE_INVERSE_WINDING and CAIRO_FILL_RULE_INVERSE_EVEN_ODD
* Fix clipping to work for all operators. The equation we have come up
with is:
((src Op dest) In clip) Add (dest Out clip)
* Split cairo_format_t into two things:
- An enumeration that determines the "capabilities" of a surface -
A vs. ARGB. vs. RGB
- An enumeration that determines a specific in-memory representation
of data. (A1/A8/ARGB32/etc.. Could be extensible to things like
RGBA32_BYTES_NONPREMULTIPLIED. Some consistent naming convention would
be be good.)
One issue here is that some interfaces, like cairo_surface_create_similar()
might be useful with either one. We might want to create an A1 surface
compatible with the backend (are there examples other than A1? Should
bilevel just be another "capability"?), or we might want to just create
an alpha surface without caring about the depth.
If we want to support this, we could do something like:
typedef enum cairo_pixel_format_t {
CAIRO_PIXEL_FORMAT_A8 = CAIRO_FORMAT_ALPHA,
CAIRO_PIXEL_FORMAT_RGB24 = CAIRO_FORMAT_RGB,
CAIRO_PIXEL_FORMAT_A1,
};
To allow passing either in.
(I don't particularly like this idea for create_similar() because then you
aren't really saying ALPHA-dont-care, you are saying ALPHA-8. I think it
would be better to have a separate path for create_similar_with_pixel_format()
if we need that. But it might be useful for cairo_image_surface_create() ...
people are going to screw up and pass CAIRO_FORMAT_RGB into that, and if it
"just worked" that would save people trouble....)
* Clean up the API in preparation for freezing and release.
* Make a more interesting PS backend, (other than the current
"giant-image for every page" approach).
* Figure out what to do with DPI for image/png backends.
* Change stroke code to go through one giant polygon. This will fix
problems with stroking self-intersecting paths.
* Re-work the backend clipping interface to use geometry rather than
images.
* Fix the intersection problem, (see reference to Hobby's paper
mentioned in cairo_traps.c).
* Add a new cairo_text_glyphs function (a sort of bridge between the
toy and the real text API):
> void
> cairo_text_glyphs (cairo_t *cr, const unsigned char *utf8,
> cairo_glyph_t *glyphs, int *num_glyphs);
>
> with num_glyphs as an input-output parameter. The behavior of this
> function would be such that calling:
>
> cairo_text_glyphs (cr, string, glyphs, &num_glyphs);
> cairo_show_glyphs (cr, glyphs, num_glyphs);
>
> would be equivalent too:
>
> cairo_show_text (cr, string);
>
> as long as the original size of glyphs/num_glyphs was large
> enough.
* Implement dashing for cairo_curve_to.
* Implement support for programmatic patterns, (ie. figure out how to
do gradients the Right Way).
* Implement cairo_arc_to.
* Stroking closed, degenerate paths should still draw caps. Round
caps are easy; square should probably draw an axis-aligned square.
* It would be nice if the user had a mechanism to reliably draw custom
caps. One approach here would be to provide the coordinates of the
butt cap faces so that the user can append seamless caps to the
current path. We may also need to provide the coordinates of the
faces of every dash as well.
* Should add geometry pruning as appropriate.
* We need a way to get at the image data after something
like cairo_surface_create_similar with the image backend.
* Three suggestions from Owen that will help GTK+ performance:
- The ability have an additional rectangle-list clip in the
Xlib surface. Frequently during an expose event, GTK+ is
drawing L shaped areas
XXXXXX
X.....
X.....
And passing the real clip to the server is going to save
a lot of pixel operations that will be thrown away.
- The ability to pass in a width/height to cairo_xlib_surface_create()
to avoid a round-trip. (Round-trips are bad to the point where
querying the the server is something you don't want to do in
production software)
- More of a future thing, the ability to hint to to cairo that
the contents of the Xlib surface passed to
cairo_xlib_surface_create() are a solid fill ... this is
very much the normal case for GTK+ usage and allows for
big optimization in the no-RENDER case.
(see http://mail.gnome.org/archives/gtk-devel-list/2003-March/msg00045.html
* Verification, profiling, optimization.
centi_unfinished.svg may provide a good test case.
* Implement copy-on-write regions in pixman as a more complete
solution than the BAD_NESTING stuff to Owen's "Clip region problems"
thread.
|
