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