TODO

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