michael@0: - Go through things marked FIXME michael@0: michael@0: - Add calls to prepare and finish access where necessary. grep for michael@0: ACCESS_MEM, and make sure they are correctly wrapped in prepare michael@0: and finish. michael@0: michael@0: - restore READ/WRITE in the fbcompose combiners since they sometimes michael@0: store directly to destination drawables. michael@0: michael@0: - It probably makes sense to move the more strange X region API michael@0: into pixman as well, but guarded with PIXMAN_XORG_COMPATIBILITY michael@0: michael@0: - Reinstate the FbBits typedef? At the moment we don't michael@0: even have the FbBits type; we just use uint32_t everywhere. michael@0: michael@0: Keith says in bug 2335: michael@0: michael@0: The 64-bit code in fb (pixman) is probably broken; it hasn't been michael@0: used in quite some time as PCI (and AGP) is 32-bits wide, so michael@0: doing things 64-bits at a time is a net loss. To quickly fix michael@0: this, I suggest just using 32-bit datatypes by setting michael@0: IC_SHIFT to 5 for all machines. michael@0: michael@0: - Consider whether calling regions region16 is really such a great michael@0: idea Vlad wants 32 bit regions for Cairo. This will break X server michael@0: ABI, but should otherwise be mostly harmless, though a michael@0: pixman_region_get_boxes16() may be useful. michael@0: michael@0: - Make source clipping optional. michael@0: - done: source clipping happens through an indirection. michael@0: still needs to make the indirection settable. (And call it michael@0: from X) michael@0: michael@0: - Consider optimizing the 8/16 bit solid fills in pixman-util.c by michael@0: storing more than one value at a time. michael@0: michael@0: - Add an image cache to prevent excessive malloc/free. Note that pixman michael@0: needs to be thread safe when used from cairo. michael@0: michael@0: - Review the pixman_format_code_t enum to make sure it will support michael@0: future formats. Some formats we will probably need: michael@0: michael@0: ARGB/ABGR with 16/32/64 bit integer/floating channels michael@0: YUV2, michael@0: YV12 michael@0: michael@0: Also we may need the ability to distinguish between PICT_c8 and michael@0: PICT_x4c4. (This could be done by interpreting the A channel as michael@0: the depth for TYPE_COLOR and TYPE_GRAY formats). michael@0: michael@0: A possibility may be to reserve the two top bits and make them michael@0: encode "number of places to shift the channel widths given" Since michael@0: these bits are 00 at the moment everything will continue to work, michael@0: but these additional widths will be allowed: michael@0: michael@0: All even widths between 18-32 michael@0: All multiples of four widths between 33 and 64 michael@0: All multiples of eight between 64 and 128 michael@0: michael@0: This means things like r21g22b21 won't work - is that worth michael@0: worrying about? I don't think so. And of course the bpp field michael@0: can't handle a depth of over 256, so > 64 bit channels arent' michael@0: really all that useful. michael@0: michael@0: We could reserve one extra bit to indicate floating point, but michael@0: we may also just add michael@0: michael@0: PIXMAN_TYPE_ARGB_FLOAT michael@0: PIXMAN_TYPE_BGRA_FLOAT michael@0: PIXMAN_TYPE_A_FLOAT michael@0: michael@0: image types. With five bits we can support up to 32 different michael@0: format types, which should be enough for everybody, even if we michael@0: decide to support all the various video formats here: michael@0: michael@0: http://www.fourcc.org/yuv.php michael@0: michael@0: It may make sense to have a PIXMAN_TYPE_YUV, and then use the michael@0: channel bits to specify the exact subtype. michael@0: michael@0: What about color spaces such a linear vs. srGB etc.? michael@0: michael@0: michael@0: done: michael@0: michael@0: - Run cairo test suite; fix bugs michael@0: - one bug in source-scale-clip michael@0: michael@0: - Remove the warning suppression in the ACCESS_MEM macro and fix the michael@0: warnings that are real michael@0: - irrelevant now. michael@0: michael@0: - make the wrapper functions global instead of image specific michael@0: - this won't work since pixman is linked to both fb and wfb michael@0: michael@0: - Add non-mmx solid fill michael@0: michael@0: - Make sure the endian-ness macros are defined correctly. michael@0: michael@0: - The rectangles in a region probably shouldn't be returned const as michael@0: the X server will be changing them. michael@0: michael@0: - Right now we _always_ have a clip region, which is empty by default. michael@0: Why does this work at all? It probably doesn't. The server michael@0: distinguishes two cases, one where nothing is clipped (CT_NONE), and michael@0: one where there is a clip region (CT_REGION). michael@0: michael@0: - Default clip region should be the full image michael@0: michael@0: - Test if pseudo color still works. It does, but it also shows that michael@0: copying a pixman_indexed_t on every composite operation is not michael@0: going to fly. So, for now set_indexed() does not copy the michael@0: indexed table. michael@0: michael@0: Also just the malloc() to allocate a pixman image shows up pretty michael@0: high. michael@0: michael@0: Options include michael@0: michael@0: - Make all the setters not copy their arguments michael@0: michael@0: - Possibly combined with going back to the stack allocated michael@0: approach that we already use for regions. michael@0: michael@0: - Keep a cached pixman_image_t around for every picture. It would michael@0: have to be kept uptodate every time something changes about the michael@0: picture. michael@0: michael@0: - Break the X server ABI and simply have the relevant parameter michael@0: stored in the pixman image. This would have the additional benefits michael@0: that: michael@0: michael@0: - We can get rid of the annoying repeat field which is duplicated michael@0: elsewhere. michael@0: michael@0: - We can use pixman_color_t and pixman_gradient_stop_t michael@0: etc. instead of the types that are defined in michael@0: renderproto.h michael@0: