TODO

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