[Pixman] [PATCH] Remove TODO file
Søren Sandmann
sandmann at cs.au.dk
Fri Aug 24 10:04:47 PDT 2012
From: Søren Sandmann Pedersen <ssp at redhat.com>
It's obsolete and irrelevant.
---
TODO | 271 ------------------------------------------------------------------
1 files changed, 0 insertions(+), 271 deletions(-)
delete mode 100644 TODO
diff --git a/TODO b/TODO
deleted file mode 100644
index 4434ec7..0000000
--- a/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
-
--
1.7.4
More information about the Pixman
mailing list