[cairo] Pixel RGB Values...

[Carl Worth]

[Sorry for the late reply here---so many topics in one email made it
easy for me to postpone replying. But a recent change in tools I use
for reading email makes it harder for me to keep postponing, which is
a good thing.]

On Wed, Jul 22, 2009 at 10:14:38PM +0100, Chris Wilson wrote:
> On Wed, 2009-07-22 at 12:40 -0700, Carl Worth wrote:
> > "map_image" perhaps?
> 
> Taking a leaf out of other API, maybe cairo_surface_map_as_image() or
> cairo_surface_map_to_image(). I think the 'to' is a good balance to the
> 'for' that is already in use in the other direction.

Yes, I do like that. map_to_image is better than map_image.

> > And maybe that's what we really want, but it seems oddly asymmetrix to
> > me.
> 
> I'm misinterpreting what you're saying here, because I don't see the
> confusion in what you are trying to point out. 
> 
> The choices that we have whilst the user has the surface mapped for
> direct access are:
> 
> 1. discard all rendering to the original surface.
> 
> 2. keep rendering to the original surface, but without syncing to the
> mapped image buffer, and overwriting the changes with the contents of
> the image buffer when the surface is unmapped.
> 
> 3. redirect the rendering to the image buffer such that the mapped
> buffer stays in sync.

A very nice description, thank you.

I had understood your original description as being option #2, but it
seemed messy to me, (easy to get image updates partially overwriting a
vector operation and getting incorrect results). Option #3 complicates
the implementation considerably, without, I think entirely eliminating
all the problems.

So I think I'd be most inclined to go with option #1.

> On the subject of wacky_format_t, what did you think of Soeren's
> suggestion to just use the pixman_format_code_t for cairo_format_t?

I may have missed it. Do you have a more concrete proposal for me to
consider?

-Carl