I'm trying to keep the diff size down. So only new code gets lookup tables. Existing switch statements remain.
l301: The old description was incomplete (did not address 16/24-bpp formats) and for 3-byte/24-bpp formats was misleadingly wrong. You can see this in that we've had format "bgr_888" for a long time but it apparently never worked. I've augmented it with new format rgb_888 that actually does work, and verified the right colours appear on screen.
You can't entirely get away from endianess switching if you want pixel formats that are addressable as whole uint32's. Either you use our definition, which allows the client to write pixels endian-independently (but requires endian-specific pixel format types), or you use the other traditional definition like OpenGL that describes the byte order as always literal big endian. But that just moves the #ifdef problem out of the display server and into the client code.
I'm trying to keep the diff size down. So only new code gets lookup tables. Existing switch statements remain.
l301: The old description was incomplete (did not address 16/24-bpp formats) and for 3-byte/24-bpp formats was misleadingly wrong. You can see this in that we've had format "bgr_888" for a long time but it apparently never worked. I've augmented it with new format rgb_888 that actually does work, and verified the right colours appear on screen.
You can't entirely get away from endianess switching if you want pixel formats that are addressable as whole uint32's. Either you use our definition, which allows the client to write pixels endian- independently (but requires endian-specific pixel format types), or you use the other traditional definition like OpenGL that describes the byte order as always literal big endian. But that just moves the #ifdef problem out of the display server and into the client code.