diff options
Diffstat (limited to 'pixman/TODO')
| -rw-r--r-- | pixman/TODO | 542 |
1 files changed, 271 insertions, 271 deletions
diff --git a/pixman/TODO b/pixman/TODO index 4434ec7cb..465abe7b5 100644 --- a/pixman/TODO +++ b/pixman/TODO @@ -1,271 +1,271 @@ - - Testing - - Test implementations against each other - - Test both with and without the operator strength reduction. - They shold be identical. - - - SSE 2 issues: - - - Use MM_HINT_NTA instead of MM_HINT_T0 - - - Use of fbCompositeOver_x888x8x8888sse2() - - - Update the RLEASING file - - - Things to keep in mind if breaking ABI: - - - There should be a guard #ifndef I_AM_EITHER_CAIRO_OR_THE_X_SERVER - - - X server will require 16.16 essentially forever. Can we get - the required precision by simply adding offset_x/y to the - relevant rendering API? - - - Get rid of workaround for X server bug. - - - pixman_image_set_indexed() should copy its argument, and X - should be ported over to use a pixman_image as the - representation of a Picture, rather than creating one on each - operation. - - - We should get rid of pixman_set_static_pointers() - - - We should get rid of the various trapezoid helper functions(). - (They only exist because they are theoretically available to - drivers). - - - 16 bit regions should be deleted - - - There should only be one trap rasterization API. - - - The PIXMAN_g8/c8/etc formats should use the A channel - to indicate the actual depth. That way PIXMAN_x4c4 and PIXMAN_c8 - won't collide. - - - Maybe bite the bullet and make configure.ac generate a pixman-types.h - file that can be included from pixman.h to avoid the #ifdef magic - in pixman.h - - - Make pixman_region_point_in() survive a NULL box, then fix up - pixman-compose.c - - - Possibly look into inlining the fetch functions - - - There is a bug with source clipping demonstrated by clip-test in the - test directory. If we interprete source clipping as given in - destination coordinates, which is probably the only sane choice, - then the result should have two red bars down the sides. - - - Test suite - - - Add a general way of dealing with architecture specific - fast-paths. The current idea is to have each operation that can - be optimized is called through a function pointer that is - initially set to an initialization function that is responsible for - setting the function pointer to the appropriate fast-path. - - - Go through things marked FIXME - - - Add calls to prepare and finish access where necessary. grep for - ACCESS_MEM, and make sure they are correctly wrapped in prepare - and finish. - - - restore READ/WRITE in the fbcompose combiners since they sometimes - store directly to destination drawables. - - - It probably makes sense to move the more strange X region API - into pixman as well, but guarded with PIXMAN_XORG_COMPATIBILITY - - - Reinstate the FbBits typedef? At the moment we don't - even have the FbBits type; we just use uint32_t everywhere. - - Keith says in bug 2335: - - The 64-bit code in fb (pixman) is probably broken; it hasn't been - used in quite some time as PCI (and AGP) is 32-bits wide, so - doing things 64-bits at a time is a net loss. To quickly fix - this, I suggest just using 32-bit datatypes by setting - IC_SHIFT to 5 for all machines. - - - Consider optimizing the 8/16 bit solid fills in pixman-util.c by - storing more than one value at a time. - - - Add an image cache to prevent excessive malloc/free. Note that pixman - needs to be thread safe when used from cairo. - - - Moving to 24.8 coordinates. This is tricky because X is still - defined as 16.16 and will be basically forever. It's possible we - could do this by adding extra offset_x/y parameters to the - trapezoid calls. The X server could then just call the API with - (0, 0). Cairo would have to make sure that the delta *within* a - batch of trapezoids does not exceed 16 bit. - - - Consider adding actual backends. Brain dump: - - A backend is something that knows how to - - - Create images - - Composite three images - - Rasterize trapezoids - - Do solid fills and blits - - These operations are provided by a vtable that the backend will - create when it is initialized. Initial backends: - - - VMX - - SSE2 - - MMX - - Plain Old C - - When the SIMD backends are initialized, they will be passed a - pointer to the Plain Old C backend that they can use for fallback - purposes. - - Images would gain a vtable as well that would contain things like - - - Read scanline - - Write scanline - - (Or even read_patch/write_patch as suggested by Keith a while - back). - - This could simplify the compositing code considerably. - - - Review the pixman_format_code_t enum to make sure it will support - future formats. Some formats we will probably need: - - ARGB/ABGR with 16/32/64 bit integer/floating channels - YUV2, - YV12 - - Also we may need the ability to distinguish between PICT_c8 and - PICT_x4c4. (This could be done by interpreting the A channel as - the depth for TYPE_COLOR and TYPE_GRAY formats). - - A possibility may be to reserve the two top bits and make them - encode "number of places to shift the channel widths given" Since - these bits are 00 at the moment everything will continue to work, - but these additional widths will be allowed: - - All even widths between 18-32 - All multiples of four widths between 33 and 64 - All multiples of eight between 64 and 128 - - This means things like r21g22b21 won't work - is that worth - worrying about? I don't think so. And of course the bpp field - can't handle a depth of over 256, so > 64 bit channels arent' - really all that useful. - - We could reserve one extra bit to indicate floating point, but - we may also just add - - PIXMAN_TYPE_ARGB_FLOAT - PIXMAN_TYPE_BGRA_FLOAT - PIXMAN_TYPE_A_FLOAT - - image types. With five bits we can support up to 32 different - format types, which should be enough for everybody, even if we - decide to support all the various video formats here: - - http://www.fourcc.org/yuv.php - - It may make sense to have a PIXMAN_TYPE_YUV, and then use the - channel bits to specify the exact subtype. - - Another possibility is to add - - PIXMAN_TYPE_ARGB_W - PIXMAN_TYPE_ARGB_WW - - where the channel widths would get 16 and 32 added to them, - respectively. - - What about color spaces such a linear vs. srGB etc.? - - -done: - -- Use pixmanFillsse2 and pixmanBltsse2 - -- Be consistent about calling sse2 sse2 - -- Rename "SSE" to "MMX_EXTENSIONS". (Deleted mmx extensions). - -- Commented-out uses of fbCompositeCopyAreasse2() - -- Consider whether calling regions region16 is really such a great - idea. Vlad wants 32 bit regions for Cairo. This will break X server - ABI, but should otherwise be mostly harmless, though a - pixman_region_get_boxes16() may be useful. - -- Altivec signal issue (Company has fix, there is also a patch by - dwmw2 in rawhide). - -- Behdad's MMX issue - see list - -- SSE2 issues: - - Crashes in Mozilla because of unaligned stack. Possible fixes - - Make use of gcc 4.2 feature to align the stack - - Write some sort of trampoline that aligns the stack - before calling SSE functions. - -- Get rid of the switch-of-doom; replace it with a big table - describing the various fast paths. - -- Make source clipping optional. - - done: source clipping happens through an indirection. - still needs to make the indirection settable. (And call it - from X) - -- Run cairo test suite; fix bugs - - one bug in source-scale-clip - - - Remove the warning suppression in the ACCESS_MEM macro and fix the - warnings that are real - - irrelevant now. - -- make the wrapper functions global instead of image specific - - this won't work since pixman is linked to both fb and wfb - -- Add non-mmx solid fill - -- Make sure the endian-ness macros are defined correctly. - -- The rectangles in a region probably shouldn't be returned const as - the X server will be changing them. - -- Right now we _always_ have a clip region, which is empty by default. - Why does this work at all? It probably doesn't. The server - distinguishes two cases, one where nothing is clipped (CT_NONE), and - one where there is a clip region (CT_REGION). - -- Default clip region should be the full image - - - Test if pseudo color still works. It does, but it also shows that - copying a pixman_indexed_t on every composite operation is not - going to fly. So, for now set_indexed() does not copy the - indexed table. - - Also just the malloc() to allocate a pixman image shows up pretty - high. - - Options include - - - Make all the setters not copy their arguments - - - Possibly combined with going back to the stack allocated - approach that we already use for regions. - - - Keep a cached pixman_image_t around for every picture. It would - have to be kept uptodate every time something changes about the - picture. - - - Break the X server ABI and simply have the relevant parameter - stored in the pixman image. This would have the additional benefits - that: - - - We can get rid of the annoying repeat field which is duplicated - elsewhere. - - - We can use pixman_color_t and pixman_gradient_stop_t - etc. instead of the types that are defined in - renderproto.h - + - Testing
+ - Test implementations against each other
+ - Test both with and without the operator strength reduction.
+ They shold be identical.
+
+ - SSE 2 issues:
+
+ - Use MM_HINT_NTA instead of MM_HINT_T0
+
+ - Use of fbCompositeOver_x888x8x8888sse2()
+
+ - Update the RLEASING file
+
+ - Things to keep in mind if breaking ABI:
+
+ - There should be a guard #ifndef I_AM_EITHER_CAIRO_OR_THE_X_SERVER
+
+ - X server will require 16.16 essentially forever. Can we get
+ the required precision by simply adding offset_x/y to the
+ relevant rendering API?
+
+ - Get rid of workaround for X server bug.
+
+ - pixman_image_set_indexed() should copy its argument, and X
+ should be ported over to use a pixman_image as the
+ representation of a Picture, rather than creating one on each
+ operation.
+
+ - We should get rid of pixman_set_static_pointers()
+
+ - We should get rid of the various trapezoid helper functions().
+ (They only exist because they are theoretically available to
+ drivers).
+
+ - 16 bit regions should be deleted
+
+ - There should only be one trap rasterization API.
+
+ - The PIXMAN_g8/c8/etc formats should use the A channel
+ to indicate the actual depth. That way PIXMAN_x4c4 and PIXMAN_c8
+ won't collide.
+
+ - Maybe bite the bullet and make configure.ac generate a pixman-types.h
+ file that can be included from pixman.h to avoid the #ifdef magic
+ in pixman.h
+
+ - Make pixman_region_point_in() survive a NULL box, then fix up
+ pixman-compose.c
+
+ - Possibly look into inlining the fetch functions
+
+ - There is a bug with source clipping demonstrated by clip-test in the
+ test directory. If we interprete source clipping as given in
+ destination coordinates, which is probably the only sane choice,
+ then the result should have two red bars down the sides.
+
+ - Test suite
+
+ - Add a general way of dealing with architecture specific
+ fast-paths. The current idea is to have each operation that can
+ be optimized is called through a function pointer that is
+ initially set to an initialization function that is responsible for
+ setting the function pointer to the appropriate fast-path.
+
+ - Go through things marked FIXME
+
+ - Add calls to prepare and finish access where necessary. grep for
+ ACCESS_MEM, and make sure they are correctly wrapped in prepare
+ and finish.
+
+ - restore READ/WRITE in the fbcompose combiners since they sometimes
+ store directly to destination drawables.
+
+ - It probably makes sense to move the more strange X region API
+ into pixman as well, but guarded with PIXMAN_XORG_COMPATIBILITY
+
+ - Reinstate the FbBits typedef? At the moment we don't
+ even have the FbBits type; we just use uint32_t everywhere.
+
+ Keith says in bug 2335:
+
+ The 64-bit code in fb (pixman) is probably broken; it hasn't been
+ used in quite some time as PCI (and AGP) is 32-bits wide, so
+ doing things 64-bits at a time is a net loss. To quickly fix
+ this, I suggest just using 32-bit datatypes by setting
+ IC_SHIFT to 5 for all machines.
+
+ - Consider optimizing the 8/16 bit solid fills in pixman-util.c by
+ storing more than one value at a time.
+
+ - Add an image cache to prevent excessive malloc/free. Note that pixman
+ needs to be thread safe when used from cairo.
+
+ - Moving to 24.8 coordinates. This is tricky because X is still
+ defined as 16.16 and will be basically forever. It's possible we
+ could do this by adding extra offset_x/y parameters to the
+ trapezoid calls. The X server could then just call the API with
+ (0, 0). Cairo would have to make sure that the delta *within* a
+ batch of trapezoids does not exceed 16 bit.
+
+ - Consider adding actual backends. Brain dump:
+
+ A backend is something that knows how to
+
+ - Create images
+ - Composite three images
+ - Rasterize trapezoids
+ - Do solid fills and blits
+
+ These operations are provided by a vtable that the backend will
+ create when it is initialized. Initial backends:
+
+ - VMX
+ - SSE2
+ - MMX
+ - Plain Old C
+
+ When the SIMD backends are initialized, they will be passed a
+ pointer to the Plain Old C backend that they can use for fallback
+ purposes.
+
+ Images would gain a vtable as well that would contain things like
+
+ - Read scanline
+ - Write scanline
+
+ (Or even read_patch/write_patch as suggested by Keith a while
+ back).
+
+ This could simplify the compositing code considerably.
+
+ - Review the pixman_format_code_t enum to make sure it will support
+ future formats. Some formats we will probably need:
+
+ ARGB/ABGR with 16/32/64 bit integer/floating channels
+ YUV2,
+ YV12
+
+ Also we may need the ability to distinguish between PICT_c8 and
+ PICT_x4c4. (This could be done by interpreting the A channel as
+ the depth for TYPE_COLOR and TYPE_GRAY formats).
+
+ A possibility may be to reserve the two top bits and make them
+ encode "number of places to shift the channel widths given" Since
+ these bits are 00 at the moment everything will continue to work,
+ but these additional widths will be allowed:
+
+ All even widths between 18-32
+ All multiples of four widths between 33 and 64
+ All multiples of eight between 64 and 128
+
+ This means things like r21g22b21 won't work - is that worth
+ worrying about? I don't think so. And of course the bpp field
+ can't handle a depth of over 256, so > 64 bit channels arent'
+ really all that useful.
+
+ We could reserve one extra bit to indicate floating point, but
+ we may also just add
+
+ PIXMAN_TYPE_ARGB_FLOAT
+ PIXMAN_TYPE_BGRA_FLOAT
+ PIXMAN_TYPE_A_FLOAT
+
+ image types. With five bits we can support up to 32 different
+ format types, which should be enough for everybody, even if we
+ decide to support all the various video formats here:
+
+ http://www.fourcc.org/yuv.php
+
+ It may make sense to have a PIXMAN_TYPE_YUV, and then use the
+ channel bits to specify the exact subtype.
+
+ Another possibility is to add
+
+ PIXMAN_TYPE_ARGB_W
+ PIXMAN_TYPE_ARGB_WW
+
+ where the channel widths would get 16 and 32 added to them,
+ respectively.
+
+ What about color spaces such a linear vs. srGB etc.?
+
+
+done:
+
+- Use pixmanFillsse2 and pixmanBltsse2
+
+- Be consistent about calling sse2 sse2
+
+- Rename "SSE" to "MMX_EXTENSIONS". (Deleted mmx extensions).
+
+- Commented-out uses of fbCompositeCopyAreasse2()
+
+- Consider whether calling regions region16 is really such a great
+ idea. Vlad wants 32 bit regions for Cairo. This will break X server
+ ABI, but should otherwise be mostly harmless, though a
+ pixman_region_get_boxes16() may be useful.
+
+- Altivec signal issue (Company has fix, there is also a patch by
+ dwmw2 in rawhide).
+
+- Behdad's MMX issue - see list
+
+- SSE2 issues:
+ - Crashes in Mozilla because of unaligned stack. Possible fixes
+ - Make use of gcc 4.2 feature to align the stack
+ - Write some sort of trampoline that aligns the stack
+ before calling SSE functions.
+
+- Get rid of the switch-of-doom; replace it with a big table
+ describing the various fast paths.
+
+- Make source clipping optional.
+ - done: source clipping happens through an indirection.
+ still needs to make the indirection settable. (And call it
+ from X)
+
+- Run cairo test suite; fix bugs
+ - one bug in source-scale-clip
+
+ - Remove the warning suppression in the ACCESS_MEM macro and fix the
+ warnings that are real
+ - irrelevant now.
+
+- make the wrapper functions global instead of image specific
+ - this won't work since pixman is linked to both fb and wfb
+
+- Add non-mmx solid fill
+
+- Make sure the endian-ness macros are defined correctly.
+
+- The rectangles in a region probably shouldn't be returned const as
+ the X server will be changing them.
+
+- Right now we _always_ have a clip region, which is empty by default.
+ Why does this work at all? It probably doesn't. The server
+ distinguishes two cases, one where nothing is clipped (CT_NONE), and
+ one where there is a clip region (CT_REGION).
+
+- Default clip region should be the full image
+
+ - Test if pseudo color still works. It does, but it also shows that
+ copying a pixman_indexed_t on every composite operation is not
+ going to fly. So, for now set_indexed() does not copy the
+ indexed table.
+
+ Also just the malloc() to allocate a pixman image shows up pretty
+ high.
+
+ Options include
+
+ - Make all the setters not copy their arguments
+
+ - Possibly combined with going back to the stack allocated
+ approach that we already use for regions.
+
+ - Keep a cached pixman_image_t around for every picture. It would
+ have to be kept uptodate every time something changes about the
+ picture.
+
+ - Break the X server ABI and simply have the relevant parameter
+ stored in the pixman image. This would have the additional benefits
+ that:
+
+ - We can get rid of the annoying repeat field which is duplicated
+ elsewhere.
+
+ - We can use pixman_color_t and pixman_gradient_stop_t
+ etc. instead of the types that are defined in
+ renderproto.h
+
|