3 - Use MM_HINT_NTA instead of MM_HINT_T0
5 - Use of fbCompositeOver_x888x8x8888sse2()
7 - Use pixmanFillsse2 and pixmanBltsse2
9 - Update the RLEASING file
11 - Things to keep in mind if breaking ABI:
13 - There should be a guard #ifndef I_AM_EITHER_CAIRO_OR_THE_X_SERVER
15 - X server will require 16.16 essentially forever. Can we get
16 the required precision by simply adding offset_x/y to the
17 relevant rendering API?
19 - pixman_image_set_indexed() should copy its argument, and X
20 should be ported over to use a pixman_image as the
21 representation of a Picture, rather than creating one on each
24 - We should get rid of pixman_set_static_pointers()
26 - We should get rid of the various trapezoid helper functions().
27 (They only exist because they are theoretically available to
30 - 16 bit regions should be deleted
32 - There should only be one trap rasterization API.
34 - The PIXMAN_g8/c8/etc formats should use the A channel
35 to indicate the actual depth. That way PIXMAN_x4c4 and PIXMAN_c8
38 - Maybe bite the bullet and make configure.ac generate a pixman-types.h
39 file that can be included from pixman.h to avoid the #ifdef magic
42 - Make pixman_region_point_in() survive a NULL box, then fix up
45 - Possibly look into inlining the fetch functions
47 - There is a bug with source clipping demonstrated by clip-test in the
48 test directory. If we interprete source clipping as given in
49 destination coordinates, which is probably the only sane choice,
50 then the result should have two red bars down the sides.
54 - Add a general way of dealing with architecture specific
55 fast-paths. The current idea is to have each operation that can
56 be optimized is called through a function pointer that is
57 initially set to an initialization function that is responsible for
58 setting the function pointer to the appropriate fast-path.
60 - Go through things marked FIXME
62 - Add calls to prepare and finish access where necessary. grep for
63 ACCESS_MEM, and make sure they are correctly wrapped in prepare
66 - restore READ/WRITE in the fbcompose combiners since they sometimes
67 store directly to destination drawables.
69 - It probably makes sense to move the more strange X region API
70 into pixman as well, but guarded with PIXMAN_XORG_COMPATIBILITY
72 - Reinstate the FbBits typedef? At the moment we don't
73 even have the FbBits type; we just use uint32_t everywhere.
75 Keith says in bug 2335:
77 The 64-bit code in fb (pixman) is probably broken; it hasn't been
78 used in quite some time as PCI (and AGP) is 32-bits wide, so
79 doing things 64-bits at a time is a net loss. To quickly fix
80 this, I suggest just using 32-bit datatypes by setting
81 IC_SHIFT to 5 for all machines.
83 - Consider optimizing the 8/16 bit solid fills in pixman-util.c by
84 storing more than one value at a time.
86 - Add an image cache to prevent excessive malloc/free. Note that pixman
87 needs to be thread safe when used from cairo.
89 - Moving to 24.8 coordinates. This is tricky because X is still
90 defined as 16.16 and will be basically forever. It's possible we
91 could do this by adding extra offset_x/y parameters to the
92 trapezoid calls. The X server could then just call the API with
93 (0, 0). Cairo would have to make sure that the delta *within* a
94 batch of trapezoids does not exceed 16 bit.
96 - Consider adding actual backends. Brain dump:
98 A backend is something that knows how to
101 - Composite three images
102 - Rasterize trapezoids
103 - Do solid fills and blits
105 These operations are provided by a vtable that the backend will
106 create when it is initialized. Initial backends:
113 When the SIMD backends are initialized, they will be passed a
114 pointer to the Plain Old C backend that they can use for fallback
117 Images would gain a vtable as well that would contain things like
122 (Or even read_patch/write_patch as suggested by Keith a while
125 This could simplify the compositing code considerably.
127 - Review the pixman_format_code_t enum to make sure it will support
128 future formats. Some formats we will probably need:
130 ARGB/ABGR with 16/32/64 bit integer/floating channels
134 Also we may need the ability to distinguish between PICT_c8 and
135 PICT_x4c4. (This could be done by interpreting the A channel as
136 the depth for TYPE_COLOR and TYPE_GRAY formats).
138 A possibility may be to reserve the two top bits and make them
139 encode "number of places to shift the channel widths given" Since
140 these bits are 00 at the moment everything will continue to work,
141 but these additional widths will be allowed:
143 All even widths between 18-32
144 All multiples of four widths between 33 and 64
145 All multiples of eight between 64 and 128
147 This means things like r21g22b21 won't work - is that worth
148 worrying about? I don't think so. And of course the bpp field
149 can't handle a depth of over 256, so > 64 bit channels arent'
150 really all that useful.
152 We could reserve one extra bit to indicate floating point, but
155 PIXMAN_TYPE_ARGB_FLOAT
156 PIXMAN_TYPE_BGRA_FLOAT
159 image types. With five bits we can support up to 32 different
160 format types, which should be enough for everybody, even if we
161 decide to support all the various video formats here:
163 http://www.fourcc.org/yuv.php
165 It may make sense to have a PIXMAN_TYPE_YUV, and then use the
166 channel bits to specify the exact subtype.
168 Another possibility is to add
173 where the channel widths would get 16 and 32 added to them,
176 What about color spaces such a linear vs. srGB etc.?
181 - Be consistent about calling sse2 sse2
183 - Rename "SSE" to "MMX_EXTENSIONS". (Deleted mmx extensions).
185 - Commented-out uses of fbCompositeCopyAreasse2()
187 - Consider whether calling regions region16 is really such a great
188 idea. Vlad wants 32 bit regions for Cairo. This will break X server
189 ABI, but should otherwise be mostly harmless, though a
190 pixman_region_get_boxes16() may be useful.
192 - Altivec signal issue (Company has fix, there is also a patch by
195 - Behdad's MMX issue - see list
198 - Crashes in Mozilla because of unaligned stack. Possible fixes
199 - Make use of gcc 4.2 feature to align the stack
200 - Write some sort of trampoline that aligns the stack
201 before calling SSE functions.
203 - Get rid of the switch-of-doom; replace it with a big table
204 describing the various fast paths.
206 - Make source clipping optional.
207 - done: source clipping happens through an indirection.
208 still needs to make the indirection settable. (And call it
211 - Run cairo test suite; fix bugs
212 - one bug in source-scale-clip
214 - Remove the warning suppression in the ACCESS_MEM macro and fix the
215 warnings that are real
218 - make the wrapper functions global instead of image specific
219 - this won't work since pixman is linked to both fb and wfb
221 - Add non-mmx solid fill
223 - Make sure the endian-ness macros are defined correctly.
225 - The rectangles in a region probably shouldn't be returned const as
226 the X server will be changing them.
228 - Right now we _always_ have a clip region, which is empty by default.
229 Why does this work at all? It probably doesn't. The server
230 distinguishes two cases, one where nothing is clipped (CT_NONE), and
231 one where there is a clip region (CT_REGION).
233 - Default clip region should be the full image
235 - Test if pseudo color still works. It does, but it also shows that
236 copying a pixman_indexed_t on every composite operation is not
237 going to fly. So, for now set_indexed() does not copy the
240 Also just the malloc() to allocate a pixman image shows up pretty
245 - Make all the setters not copy their arguments
247 - Possibly combined with going back to the stack allocated
248 approach that we already use for regions.
250 - Keep a cached pixman_image_t around for every picture. It would
251 have to be kept uptodate every time something changes about the
254 - Break the X server ABI and simply have the relevant parameter
255 stored in the pixman image. This would have the additional benefits
258 - We can get rid of the annoying repeat field which is duplicated
261 - We can use pixman_color_t and pixman_gradient_stop_t
262 etc. instead of the types that are defined in