Used synchronise script to update files

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

+