1.1 --- /dev/null Thu Jan 01 00:00:00 1970 +0000
1.2 +++ b/gfx/cairo/libpixman/TODO Wed Dec 31 06:09:35 2014 +0100
1.3 @@ -0,0 +1,139 @@
1.4 + - Go through things marked FIXME
1.5 +
1.6 + - Add calls to prepare and finish access where necessary. grep for
1.7 + ACCESS_MEM, and make sure they are correctly wrapped in prepare
1.8 + and finish.
1.9 +
1.10 + - restore READ/WRITE in the fbcompose combiners since they sometimes
1.11 + store directly to destination drawables.
1.12 +
1.13 + - It probably makes sense to move the more strange X region API
1.14 + into pixman as well, but guarded with PIXMAN_XORG_COMPATIBILITY
1.15 +
1.16 + - Reinstate the FbBits typedef? At the moment we don't
1.17 + even have the FbBits type; we just use uint32_t everywhere.
1.18 +
1.19 + Keith says in bug 2335:
1.20 +
1.21 + The 64-bit code in fb (pixman) is probably broken; it hasn't been
1.22 + used in quite some time as PCI (and AGP) is 32-bits wide, so
1.23 + doing things 64-bits at a time is a net loss. To quickly fix
1.24 + this, I suggest just using 32-bit datatypes by setting
1.25 + IC_SHIFT to 5 for all machines.
1.26 +
1.27 + - Consider whether calling regions region16 is really such a great
1.28 + idea Vlad wants 32 bit regions for Cairo. This will break X server
1.29 + ABI, but should otherwise be mostly harmless, though a
1.30 + pixman_region_get_boxes16() may be useful.
1.31 +
1.32 + - Make source clipping optional.
1.33 + - done: source clipping happens through an indirection.
1.34 + still needs to make the indirection settable. (And call it
1.35 + from X)
1.36 +
1.37 + - Consider optimizing the 8/16 bit solid fills in pixman-util.c by
1.38 + storing more than one value at a time.
1.39 +
1.40 + - Add an image cache to prevent excessive malloc/free. Note that pixman
1.41 + needs to be thread safe when used from cairo.
1.42 +
1.43 + - Review the pixman_format_code_t enum to make sure it will support
1.44 + future formats. Some formats we will probably need:
1.45 +
1.46 + ARGB/ABGR with 16/32/64 bit integer/floating channels
1.47 + YUV2,
1.48 + YV12
1.49 +
1.50 + Also we may need the ability to distinguish between PICT_c8 and
1.51 + PICT_x4c4. (This could be done by interpreting the A channel as
1.52 + the depth for TYPE_COLOR and TYPE_GRAY formats).
1.53 +
1.54 + A possibility may be to reserve the two top bits and make them
1.55 + encode "number of places to shift the channel widths given" Since
1.56 + these bits are 00 at the moment everything will continue to work,
1.57 + but these additional widths will be allowed:
1.58 +
1.59 + All even widths between 18-32
1.60 + All multiples of four widths between 33 and 64
1.61 + All multiples of eight between 64 and 128
1.62 +
1.63 + This means things like r21g22b21 won't work - is that worth
1.64 + worrying about? I don't think so. And of course the bpp field
1.65 + can't handle a depth of over 256, so > 64 bit channels arent'
1.66 + really all that useful.
1.67 +
1.68 + We could reserve one extra bit to indicate floating point, but
1.69 + we may also just add
1.70 +
1.71 + PIXMAN_TYPE_ARGB_FLOAT
1.72 + PIXMAN_TYPE_BGRA_FLOAT
1.73 + PIXMAN_TYPE_A_FLOAT
1.74 +
1.75 + image types. With five bits we can support up to 32 different
1.76 + format types, which should be enough for everybody, even if we
1.77 + decide to support all the various video formats here:
1.78 +
1.79 + http://www.fourcc.org/yuv.php
1.80 +
1.81 + It may make sense to have a PIXMAN_TYPE_YUV, and then use the
1.82 + channel bits to specify the exact subtype.
1.83 +
1.84 + What about color spaces such a linear vs. srGB etc.?
1.85 +
1.86 +
1.87 +done:
1.88 +
1.89 +- Run cairo test suite; fix bugs
1.90 + - one bug in source-scale-clip
1.91 +
1.92 + - Remove the warning suppression in the ACCESS_MEM macro and fix the
1.93 + warnings that are real
1.94 + - irrelevant now.
1.95 +
1.96 +- make the wrapper functions global instead of image specific
1.97 + - this won't work since pixman is linked to both fb and wfb
1.98 +
1.99 +- Add non-mmx solid fill
1.100 +
1.101 +- Make sure the endian-ness macros are defined correctly.
1.102 +
1.103 +- The rectangles in a region probably shouldn't be returned const as
1.104 + the X server will be changing them.
1.105 +
1.106 +- Right now we _always_ have a clip region, which is empty by default.
1.107 + Why does this work at all? It probably doesn't. The server
1.108 + distinguishes two cases, one where nothing is clipped (CT_NONE), and
1.109 + one where there is a clip region (CT_REGION).
1.110 +
1.111 +- Default clip region should be the full image
1.112 +
1.113 + - Test if pseudo color still works. It does, but it also shows that
1.114 + copying a pixman_indexed_t on every composite operation is not
1.115 + going to fly. So, for now set_indexed() does not copy the
1.116 + indexed table.
1.117 +
1.118 + Also just the malloc() to allocate a pixman image shows up pretty
1.119 + high.
1.120 +
1.121 + Options include
1.122 +
1.123 + - Make all the setters not copy their arguments
1.124 +
1.125 + - Possibly combined with going back to the stack allocated
1.126 + approach that we already use for regions.
1.127 +
1.128 + - Keep a cached pixman_image_t around for every picture. It would
1.129 + have to be kept uptodate every time something changes about the
1.130 + picture.
1.131 +
1.132 + - Break the X server ABI and simply have the relevant parameter
1.133 + stored in the pixman image. This would have the additional benefits
1.134 + that:
1.135 +
1.136 + - We can get rid of the annoying repeat field which is duplicated
1.137 + elsewhere.
1.138 +
1.139 + - We can use pixman_color_t and pixman_gradient_stop_t
1.140 + etc. instead of the types that are defined in
1.141 + renderproto.h
1.142 +
