[cairo] Plans for 1.6?

[Keith Packard]

On Tue, 2007-11-27 at 22:42 -0800, Carl Worth wrote:
> On Tue, 27 Nov 2007 19:59:16 -0800, Keith Packard wrote:
> > Do you want native drawing to pseudo color? Or do you want the ability
> > to paint in a local RGB buffer and then copy to pseudo color? The latter
> > seems like it will be a lot faster (Render support on pseudo color
> > hardware seems unlikely), and will certainly give better looking results
> > as we can even dither if desired.
> 
> The latter definitely sounds like the right approach.
> 
> But anything that doesn't just trigger an assertion failure will be
> fine by me. I really don't care about quality for this, (nor have I
> seen evidence that anyone else does). So I was tempted to just make
> sure the patches that have been proposed aren't totally insane. I
> don't know what they do, but there are attempts here:
> 
> 	Cairo doesn't support 8-bit pseudocolor visuals
> 	https://bugs.freedesktop.org/show_bug.cgi?id=4945

That replaces GetImage/PutImage with conversion to 24 bit RGB, but it
doesn't appear to be creating a suitable colormap, and it will fail when
colors in the colormap change (due to reallocation). 

To make this work reliably, it would need to either create an X standard
colormap (not the best choice as it's a pure cube), or allocate a custom
cairo colormap (non-standard, but we presume that the user is running
more than one cairo app). It would then always write only colors in the
cairo colormap, but when doing GetImage, it would need to always invoke
XQueryColors along with XGetImage so that the pixel values would be
interpreted correctly.

It also doesn't handle applications with private colormaps, but I think
that's not very interesting for cairo.

Because it doesn't perform all of its work locally and only do PutImage
requests, all of the color values will be seriously warped by the
conversion to 8 bits, making any incremental rendering a fairly bad
proposition. 

I don't know how hard it would be to make the Xlib backend create local
copies of the object and do PutImages on flush, but that would make this
reasonably performant as well as reasonably good looking. Do we have any
kind of damage bounding box available to avoid doing huge put images
each time something changes? And, how would we notify the library that
the drawable in question should not be kept locally? 

If all you want is to make that patch work, then you'd just need to add
some X standard colormap detection stuff, and some color allocation
stuff to make sure the colormap is usable, then populate the rgb->pixel
conversion array with only known read-only pixels (black, white and the
contents of the standard or cairo colormap). Doing XQueryColors before
each XGetImage on foreign objects would fix any external color
allocation effects.

-- 
keith.packard at intel.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.cairographics.org/archives/cairo/attachments/20071127/66d0f8dc/attachment.pgp