The Tor Browser / file comparison
comparison: gfx/cairo/libpixman/TODO
gfx/cairo/libpixman/TODO
- branch
- TOR_BUG_9701
- changeset 8
- 97036ab72558
equal
deleted
inserted
replaced
| -1:000000000000 | 0:3699733e939f |
|---|---|
| 1 - Go through things marked FIXME | |
| 2 | |
| 3 - Add calls to prepare and finish access where necessary. grep for | |
| 4 ACCESS_MEM, and make sure they are correctly wrapped in prepare | |
| 5 and finish. | |
| 6 | |
| 7 - restore READ/WRITE in the fbcompose combiners since they sometimes | |
| 8 store directly to destination drawables. | |
| 9 | |
| 10 - It probably makes sense to move the more strange X region API | |
| 11 into pixman as well, but guarded with PIXMAN_XORG_COMPATIBILITY | |
| 12 | |
| 13 - Reinstate the FbBits typedef? At the moment we don't | |
| 14 even have the FbBits type; we just use uint32_t everywhere. | |
| 15 | |
| 16 Keith says in bug 2335: | |
| 17 | |
| 18 The 64-bit code in fb (pixman) is probably broken; it hasn't been | |
| 19 used in quite some time as PCI (and AGP) is 32-bits wide, so | |
| 20 doing things 64-bits at a time is a net loss. To quickly fix | |
| 21 this, I suggest just using 32-bit datatypes by setting | |
| 22 IC_SHIFT to 5 for all machines. | |
| 23 | |
| 24 - Consider whether calling regions region16 is really such a great | |
| 25 idea Vlad wants 32 bit regions for Cairo. This will break X server | |
| 26 ABI, but should otherwise be mostly harmless, though a | |
| 27 pixman_region_get_boxes16() may be useful. | |
| 28 | |
| 29 - Make source clipping optional. | |
| 30 - done: source clipping happens through an indirection. | |
| 31 still needs to make the indirection settable. (And call it | |
| 32 from X) | |
| 33 | |
| 34 - Consider optimizing the 8/16 bit solid fills in pixman-util.c by | |
| 35 storing more than one value at a time. | |
| 36 | |
| 37 - Add an image cache to prevent excessive malloc/free. Note that pixman | |
| 38 needs to be thread safe when used from cairo. | |
| 39 | |
| 40 - Review the pixman_format_code_t enum to make sure it will support | |
| 41 future formats. Some formats we will probably need: | |
| 42 | |
| 43 ARGB/ABGR with 16/32/64 bit integer/floating channels | |
| 44 YUV2, | |
| 45 YV12 | |
| 46 | |
| 47 Also we may need the ability to distinguish between PICT_c8 and | |
| 48 PICT_x4c4. (This could be done by interpreting the A channel as | |
| 49 the depth for TYPE_COLOR and TYPE_GRAY formats). | |
| 50 | |
| 51 A possibility may be to reserve the two top bits and make them | |
| 52 encode "number of places to shift the channel widths given" Since | |
| 53 these bits are 00 at the moment everything will continue to work, | |
| 54 but these additional widths will be allowed: | |
| 55 | |
| 56 All even widths between 18-32 | |
| 57 All multiples of four widths between 33 and 64 | |
| 58 All multiples of eight between 64 and 128 | |
| 59 | |
| 60 This means things like r21g22b21 won't work - is that worth | |
| 61 worrying about? I don't think so. And of course the bpp field | |
| 62 can't handle a depth of over 256, so > 64 bit channels arent' | |
| 63 really all that useful. | |
| 64 | |
| 65 We could reserve one extra bit to indicate floating point, but | |
| 66 we may also just add | |
| 67 | |
| 68 PIXMAN_TYPE_ARGB_FLOAT | |
| 69 PIXMAN_TYPE_BGRA_FLOAT | |
| 70 PIXMAN_TYPE_A_FLOAT | |
| 71 | |
| 72 image types. With five bits we can support up to 32 different | |
| 73 format types, which should be enough for everybody, even if we | |
| 74 decide to support all the various video formats here: | |
| 75 | |
| 76 http://www.fourcc.org/yuv.php | |
| 77 | |
| 78 It may make sense to have a PIXMAN_TYPE_YUV, and then use the | |
| 79 channel bits to specify the exact subtype. | |
| 80 | |
| 81 What about color spaces such a linear vs. srGB etc.? | |
| 82 | |
| 83 | |
| 84 done: | |
| 85 | |
| 86 - Run cairo test suite; fix bugs | |
| 87 - one bug in source-scale-clip | |
| 88 | |
| 89 - Remove the warning suppression in the ACCESS_MEM macro and fix the | |
| 90 warnings that are real | |
| 91 - irrelevant now. | |
| 92 | |
| 93 - make the wrapper functions global instead of image specific | |
| 94 - this won't work since pixman is linked to both fb and wfb | |
| 95 | |
| 96 - Add non-mmx solid fill | |
| 97 | |
| 98 - Make sure the endian-ness macros are defined correctly. | |
| 99 | |
| 100 - The rectangles in a region probably shouldn't be returned const as | |
| 101 the X server will be changing them. | |
| 102 | |
| 103 - Right now we _always_ have a clip region, which is empty by default. | |
| 104 Why does this work at all? It probably doesn't. The server | |
| 105 distinguishes two cases, one where nothing is clipped (CT_NONE), and | |
| 106 one where there is a clip region (CT_REGION). | |
| 107 | |
| 108 - Default clip region should be the full image | |
| 109 | |
| 110 - Test if pseudo color still works. It does, but it also shows that | |
| 111 copying a pixman_indexed_t on every composite operation is not | |
| 112 going to fly. So, for now set_indexed() does not copy the | |
| 113 indexed table. | |
| 114 | |
| 115 Also just the malloc() to allocate a pixman image shows up pretty | |
| 116 high. | |
| 117 | |
| 118 Options include | |
| 119 | |
| 120 - Make all the setters not copy their arguments | |
| 121 | |
| 122 - Possibly combined with going back to the stack allocated | |
| 123 approach that we already use for regions. | |
| 124 | |
| 125 - Keep a cached pixman_image_t around for every picture. It would | |
| 126 have to be kept uptodate every time something changes about the | |
| 127 picture. | |
| 128 | |
| 129 - Break the X server ABI and simply have the relevant parameter | |
| 130 stored in the pixman image. This would have the additional benefits | |
| 131 that: | |
| 132 | |
| 133 - We can get rid of the annoying repeat field which is duplicated | |
| 134 elsewhere. | |
| 135 | |
| 136 - We can use pixman_color_t and pixman_gradient_stop_t | |
| 137 etc. instead of the types that are defined in | |
| 138 renderproto.h | |
| 139 |
