Re: [Tuxpaint-devel] some more investigation on grass plugin
An award-winning drawing program for children of all ages
Brought to you by:
wkendrick
From: Albert C. <aca...@gm...> - 2007-12-11 04:40:10
|
On Dec 10, 2007 10:53 AM, Alessandro Pasotti <apa...@gm...> wrote: > the api passes to the plugin a getpixel function pointer chosen from > the getpixels pool with the canvas color depth, which could be > different from the color depth of the image. > > Since I'm running the test in a Xephyr maemo SDK emulator, the color > depth is probably lower than a standard true color X display. Maybe we need two getpixel functions. Maybe we need to go back to the old way, where the getpixel function looks at the surface to determine the type. The decision could be made with an array of function pointers or with if..else; best performance will depend on the CPU. Some things to consider are: If the user data is not kept as 8:8:8, it will get mangled when the drawings are opened and saved. Mangling data is rude. Keeping data in 8:8:8 format requires more memory. We need 8:8:8 when we want to add an alpha channel. (it is of course 8:8:8:8 then) We thus can not escape dealing with this format, even if we wish to. Working with 8:8:8 data is generally fast. This is because the CPU can address individual bytes, but can not address the components of a 5:5:5 or 5:6:5 pixel. A rapidly declining number of systems use a display depth that is not 8:8:8. We can not avoid color problem if we use 5:6:5. There are operations, such as blur, that will tend to make things turn purple or green if the number of bits is not balanced. For internal use, 16:16:16 has some advantages. It can hold 8:8:8 sRGB while being linear. This would let us avoid conversion to float in various places. |