TODO

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