X-Git-Url: http://review.tizen.org/git/?a=blobdiff_plain;f=TODO;h=4434ec7cb8af1f24eecec5e410020df17dece335;hb=3c57ec471e1aacc863747b82bbe0a84c6d776ab7;hp=26eab05032e400cf4413a82955b2c785d9d24a71;hpb=d466cf1d2f09f78baaafac713d6bc7d4f003b860;p=profile%2Fivi%2Fpixman.git diff --git a/TODO b/TODO index 26eab05..4434ec7 100644 --- a/TODO +++ b/TODO @@ -1,10 +1,243 @@ - - Remove the warning suppression in the ACCESS_MEM macro and fix the - warnings that are real + - 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 - - Go through things marked FIXME + - 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 @@ -36,30 +269,3 @@ etc. instead of the types that are defined in renderproto.h - - Reinstate the FbBits conditional 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 whether calling regions region16 is really such a great idea - -- 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). - -- The rectangles in a region probably shouldn't be returned const as - the X server will be changing them. - -- Make sure the endian-ness macros are defined correctly. - -- Run cairo test suite; fix bugs - - one bug in source-scale-clip - -- Default clip region should be the full image \ No newline at end of file