xwininfo fontconfig libX11 libXau libXext libxcb mesa pixman

xkeyboard-config git update 27 Aug 2012

1 files changed, 0 insertions, 271 deletions

diff --git a/pixman/TODO b/pixman/TODO
deleted file mode 100644
index 465abe7b5..000000000
--- a/pixman/TODO
+++ /dev/null
@@ -1,271 +0,0 @@
-  - 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

-