[cairo] Integrating the new Pixman - and offer and questions

[David Hill]

>
>
>> it seems to me that we need yet another cairo_format_t,
>> CAIRO_FORMAT_CUSTOM (unless we really want to remap all of the pixman
>> supported formats – ick).
>
> Actually, I'd like to hear what people think about just remapping all
> the pixman supported formats and allowing an image surface to be
> created with any one of them. I must be missing something here, as it
> seems like a simple and effective solution to your problem. We're
> really just talking about image surfaces here, right? In that case,
> it's just a matter of passing the buck to pixman, with a couple
> exceptions that you ran into trying to reinstate R5G6B5, which can be
> solved in a general sense, AFAIK.
>
I have no objection to doing this 1-1 mapping if that is what people are 
leaning to. There clearly at a number of paths to a solution here, and I 
don't have strong feelings about any of them.

The real question boils down to how the value is going to be used. If 
most developers have the color masks (by reading them from an image 
library like png or from an Xlib visual), they may not really care about 
the "format".  If that really is the case then 
cairo_image_surface_create_for_data() already is good enough. The 
developer passes a set of color masks and we map them to a pixman format 
(where possible) and then pass back an opaque (to the developer) format 
type. Currently there is not an easy way in the new Pixman to check to 
see if a mask set is supported. I am assuming from the little code 
diving that I did that a developer can't pick an arbitrary mask set and 
expect it to work.

If I am wrong about my use case and people want to call 
cairo_image_surface_create() with any of the supported depths as a 
cairo_format_t we could do that by performing the mapping you suggest, 
though it would probably mean that I would want to expose the 
PIXMAN_FORMAT macro, perhaps as a cairo_format_to_masks() function call, 
and maybe a cairo_mask_to_format().

Dave