TODO

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