[cairo] Pixel RGB Values...

[Chris Wilson]

On Wed, 2009-07-22 at 14:52 -0700, Bill Spitzak wrote:
> >>    typedef pixman_format_code_t cairo_wacky_format_t...
> 
> Can you explain exactly what extra values you want in "wacky format" 
> that would not be useful values where a regular format is wanted? I 
> still don't understand the purpose of this.
> 
> In any case I would just add them to the normal format enumeration. If 
> in fact they make no sense for other surface types then passing them can 
> be ignored or cause errors.

Sorry, the wacky_format_t is a running joke from the discussion about
how to re-add support for RGB565. Carl is of the opinion that
cairo_format_t should only be extended when there is a demonstrable need
for a pixel format. By keeping the number of potential formats small,
the user can have a reasonable expectation that any format he chooses is
well supported throughout the entire stack. (As such the number of pixel
formats widely supported by hardware is actually quite small.)

As an alternative viewpoint, I feel annoyed at times that Cairo forces
me to convert between pixel formats and prevents me from writing a
system compositor that mixes premultiplied and unpremultiplied sources.

The compromise position of adding a cairo_wacky_format_t that makes no
promises about efficient implementation, would currently seem to be even
worse - simply adding superfluous api. However, one question I have is
how to handle high dynamic range in the current content/format system -
should we introduce a new CAIRO_CONTENT_HDR bit?

So whilst there has been a lot of talk about RGB565 support, nobody has
sent a clean patch. :-p
-ickle