[cairo] Redoing the xlib surface constructors

[Owen Taylor]

On Sat, 2005-03-12 at 08:43 -0800, Keith Packard wrote:

> Render handles indexed visuals (i.e. StaticGray, GrayScale, StaticColor 
> and PseudoColor) by treating them all the same.  For GrayScale and Pseudo
> Color, it allocates a fixed set of colors within the default colormap, you 
> can even query what those colors are.  With that in place, all of these 
> visuals become easy enough to manage -- just match the nearest color for 
> each pixel generated and lookup each pixel in the colormap.  There are 
> caches in both directions making performance acceptable.
> 
> The Render spec includes dithering, so applications could choose which 
> parts of the output would be dithered.  But, no-one has bothered to 
> implement that part of the spec, and I'm not sure it will ever happen.

There's a fairly major problem with the dithering in the RENDER spec ..
there's no way to specify a "dither offset" for a picture, so you can't
do partial re-rendering using a smaller-than-window backing store 
picture without getting artifacts at the edges of the area.

> I briefly considered allowing users to specify which colors should be used 
> for rendering, but discarded that notion as it would make sharing colors 
> between windows much harder (note that the ICCCM 'standard colormaps' 
> notion never took hold) and would require significant changes in the 
> color->pixel code which uses the wide spacing of colors in the fixed 
> Render map to reduce the precision needed within a precomputed table.

Well, there might have been an advantage to letting the user specify
whatever widely spaced color cube they wanted. GTK+ allocates it's own
big colorcube  ... and it might be nice to be able to just pass that
to render.

But it does seem like creating a whole system of colorcube objects 
would be overkill for something that nobody has ever used seriously
as far as I know.

> > I thought about mentioning it in my mail. I have the colormap in the
> > constructors, but as currently, I don't actually use it. Colormaps
> > are basically useful only for gray-scale (*), pseudo-color, and 
> > direct-color visuals.
> 
> When Render is present, the colormaps are never necessary -- applications 
> must use the colormap specified in the PictFormat.

Well, or a colormap with the same colors in the same places...

This means that large portions of the GTK+ pseudocolor API already doesn't
work on a server supporting RENDER ... you can create a private colormap 
and allocate colors in it, but you can't draw text into it.

> The only question is what should be done for these visuals on X servers 
> without Render.  Here's what I suggest:

[...]

> PseudoColor/GrayScale:		When the default visual, develop a protocol
> 				for allocating a reasonable color cube such
> 				that it can be shared.
> 
> 				When not the default visual, create a
> 				colormap and fill it in with a known color cube.
> 				This will cause flashing in some cases, but
> 				multiple cairo applications will all use
> 				the same colormap contents.

This does require the appearance of the Colormap in the Cairo API in some
form ... because Cairo is typically drawing to a pixmap, not to the window,
it doesn't even have the ability to set a colormap, even if that was a 
good idea.

So, Cairo and the application need to be in sync about what colormap
they are using. One approach would be have something like:

 Colormap cairo_xlib_get_colormap (Display *display, Visual *visual);

Where Cairo would select or create a single colormap per visual and all
drawing into that visual would assume a single colormap.. (The function
could return None for DirectColor, or could create a colormap and install
linear ramps into it, which while pointless if there is a TrueColor visual, 
does avoid returning None.)

 How does this work with the existing GTK+ API: 

  - If you create a private pseudocolor or grayscale visual, it doesn't
    work. But as mentioned above, text drawing currently doesn't work in
    GTK+ with a private pseudocolor visual and RENDER, so I don't think
    anybody is using private colormaps with GTK+ today.
 
 - For the visual/colormap from gdk_screen_get_rgb_colormap() we can
   return the Cairo colormap for the chosen GdkRGB visual. We lose
   various bits of functionality unless we spend a lot of effort on
   the Cairo code for colorcube creation, but it's not terribly 
   relevant functionality these days. (GdkRGB tries to hunt out
   an existing colormap in the default colormap and only if that
   fails allocates a private colormap.)

 - For the system default visual and colormap, it works for all visual
   types.

 - For static color/gray and truecolor it works fine because the 
   colormap is irrelevant.

 - For direct-color, who knows. GTK+ always installs a linear ramp
   into newly created direct-color visuals, and assumes in some 
   places it is left untouched. I doubt the existance of real-world
   use cases.
   
What this analysis points out to me is that simply including a 
Colormap in the function signature isn't useful because in order
to *use* a colormap, Cairo has to do lots of expensive things:

 - Query the colors in the colorcube
 - Possibly allocate colors
 - Create lookup tables

And since a Colormap is just an XID with a server-side controlled
lifetime, there is no way we can cache the results of these operations.

So, I think we should just take a Visual for the constructors. We
still have the ability to later add something like:

 cairo_xlib_surface_set_colormap (cairo_surface_t       *surface,
                                  cairo_xlib_colormap_t *colormap);

It's slightly weird to have Visual part of the constructor and not
the colormap, but I'd justify it by saying that Cairo needs the
Visual for *any* drawing, but private colormaps are these days
an esoteric part of the Xlib API ... in the category of window 
borders.

Regards,
						Owen

-------------- 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.freedesktop.org/archives/cairo/attachments/20050313/569acfff/attachment.pgp