[cairo] Redoing the xlib surface constructors

[Keith Packard]

Around 13 o'clock on Mar 13, Owen Taylor wrote:

> 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.

Not to mention that the list of available dithers and some description of 
how they work is not provided.  We'd certainly have to add more requests 
for dithering to ever work.

> 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.

The problem is that the cube must be shared among all applications or it 
has little value.

> 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.

On 256 color screens, Render is reasonably usable for anti-aliased text; 
the color cube is augmented with many gray levels to improve the 
presentation of black text on white pages.  The goal was to make things 
work on 8-bit screens about as well as most pre-Render applications worked 
on monochrome screens; with some reasonable care, applications remain 
usable if not beautiful.

And, of course, the implicit goal of making the code and spec burden as 
light as possible so that things might actually be implemented reasonably 
accurately in most environments...

> 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.

Right --  you can't use a private colormap with Render.  It's purely a 
matter of implementation effort; we could extend Render to support 
multiple color cubes, but the effort seems excessive given the limited use 
of pseudo color screens in even fairly old hardware.

> 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.

No, you need only a visual as I suggest that cairo should emulate Render
and use a static color cube for each visual.  I think we can further
restrict things so that we have a single visual for each depth, making the 
pixmap depth uniquely identify the pixel->color mapping.

> 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);

Yes, this call would be needed so that cairo-based applications could use 
the right colormap when creating windows.

>  - 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.

Yet another large section of the X protocol rendered obsolete...

> - 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.

I suggest that DirectColor be treated as if it were TrueColor by cairo; if 
the application wants to install non-monotonic ramps in the colormap, it 
will get weird results.  "don't do that".

This permits the application to do things like gamma-corrected color 
spaces (yes, it's a bad idea at 8-bits per color), or even fading effects 
using colormap hacks.

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

If we fix the depth->visual mapping, we could instead have cairo tell us 
what visual is associated with a particular depth.  That would be nicer in 
many ways, but would restrict what visuals applications used.

If this is too draconian, passing the Visual along in the API should be
sufficient.

> It's slightly weird to have Visual part of the constructor and not
> the colormap,

I guess; but we simply define the pixel<->RGB mapping as a fixed property of 
the visual irrespective of the colormap and let applications do whatever 
they like with colormaps.  Who knows -- people may come up with some weird 
use case that involves a loading the colormap with non-standard colors.

-keith


-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/cairo/attachments/20050313/52b2c22b/attachment.pgp