[cairo] Pixel RGB Values...
Bill Spitzak
spitzak at gmail.com
Thu Jul 9 09:00:27 PDT 2009
Chris Wilson wrote:
> On Thu, 2009-07-09 at 06:52 +0000, Steril 707 wrote:
>> I am working on a little image processing app, and would need to be
>> able to get the RGB values of certain pixels on a surface.
>> Is there any way to do that already with cairo at the moment? I cannot
>> find anything in the API reference on that, so I thought I should ask
>> you people here... And, if that's not possible, are there any plans
>> for this to get implemented?
>
> This is a nice timely reminder that I have something like this in
> mind. :)
>
> I've a couple of routines in mind to enable 'direct' access to the
> backing pixel storage and enable efficient upload of pixel data.
>
> The first is a convenient method for direct access (prototyped in
> cairo-drm, and used to good effect):
>
> cairo_surface_t *
> cairo_surface_map (cairo_surface_t *surface);
>
> void
> cairo_surface_unmap (cairo_surface_t *surface,
> cairo_surface_t *image);
>
> (whilst unmap looks cumbersome in that you have to remember the original
> surface, in practice this helps enforce scope and imply that such access
> is temporary. For instance, if you map a cairo-drm surface, that then
> disables rendering via the GPU until you relinquish the map.)
>
> In use, mapping a surface returns an image surface that you can use to
> manipulate pixels directly, and unmapping ensures that the changes are
> flushed to the backing surface. Internally this works just like
> acquire_dest_image()/release_dest_image() but with the extra caveat that
> the surface is exported and so we need to redirect rendering whilst the
> map is in effect. I like map/unmap (as used by pixel buffer objects in
> OpenGL), but alternative names used elsewhere include lock/unlock.
> (lock/unlock imply to me that any rendering to the original surface is
> disabled - a side-effect I don't like, but may be cause less confusion
> in the long run.)
This makes sense but I'm wondering if in fact it could be merged with
the aquire/release code. It seems to me that somebody who wants to do
this would be happy with aquire/release as well. Maybe aquire/release is
allowed to work by making a copy if nothing else works.
> The second method I think we need is for efficient pixel upload. Already
> win32 has such a scheme, but it is of general use. My proposal here is:
>
> cairo_surface_t *
> cairo_surface_create_similar_image (cairo_surface_t *target,
> cairo_content_t content,
> int width, int height);
>
> That returns an image that has appropriate backing storage to enable
> efficient upload to the target surface. (This is the best name I've come
> up with since the last time this proposal stumbled due to not finding a
> good name... ;-) The tricky issue here is whether it should take a
> content or a format. When uploading pixel data you really want to avoid
> format conversion if possible, so maybe:
>
> typedef pixman_format_code_t cairo_wacky_format_t
> cairo_surface_t *
> cairo_surface_create_similar_image (cairo_surface_t *target,
> cairo_wacky_format_t format,
> int width, height);
I think an example of what would be in "wacky format" would help to
understand why you are asking for it.
It seems to me that anybody calling this expects a particular pixel
layout. If it can't do the requested layout then a normal image is
created. Other than adding some new pixel formats I don't get why a
different enumeration is needed.
More information about the cairo
mailing list