No subject

code path, and that the result being returned here is an xlib surface
with a 32-bit depth visual. If so, then drawing with this source to
the original target will involve the X server doing 8888 -> 565
conversion.

What other option is there? Is there some other visual that the X
server provides that can store color and alpha and would work more
efficiently with a 565 target surface? If so, it should be a trivial
matter to fix cairo_surface_create_similar to use that visual in the
surface that it creates. Please let me know.

> > How can I get ahold of the actual 16 bit 565 buffer that X can directly 
> > and efficiently draw on the screen?

Now, this looks like a totally separate question. If you've got an X11
Drawable with a 565 visual, then any 16-bit buffer that exists is
accessible by the X server, and not by cairo, (which is client-side by
definition).

I don't know if the X server has any means to allow the client to get
access to that buffer, (in general it might exist in video-card memory
and not be readily accessible by the CPU anyway). Maybe some of the X
experts hacking on the OLPC know some trick, (XShm or something?). But
regardless, tricks like that would be outside the scope of cairo
anyway.

Meanwhile, I still don't completely understand what problem it is that
you are trying to solve by imagining a cairo surface that allows both
the application and the X server do have direct access to a common
buffer. If you need direct-application access to modify the buffer,
then wouldn't you be happy controlling its contents yourself? That is,
do you really need cairo to be able to draw to that same buffer as
well? If not, perhaps something outside the scope of cairo would suit
you better anyway?

I'd be glad to answer further questions on these topics, and help out
wherever possible, (including augmenting cairo as needed). But I
definitely would need some help understanding the problems better,
(because so far I haven't understood anything that could be changed in
cairo to help with any of the problems being described).

Thanks,

-Carl
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://mailman.laptop.org/pipermail/sugar/attachments/20070416/98d3be0b/attachment.pgp