[cairo] Redoing the xlib surface constructors

[Owen Taylor]

On Sun, 2005-03-13 at 12:47 -0800, Keith Packard wrote:

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

The way it worked years ago was basically a system where the first
app allocated a big colorcube, and subsequent apps hopefully were
smart enough to recognize it and reuse it. (This worked pretty
well, when the world was netscape and the GIMP, plus an xterm)

I guess in that system RENDER just plays as another app that gets
there first .. the main downside being that you end up with a smaller
colorcube than you might get otherwise. (RENDER needs to play nice
with everybody, GTK+ was optimized to make the GIMP usable on 
pseudocolor displays.)

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

But if you log into GNOME, say, it's going to look pretty sick, because
there are lots of images being drawn with RENDER as well. (Without 
RENDER, you get nice dithering via GdkRGB, but if I'm not mistaken,
no, or very ugly, text)

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

Pseudocolor support is mostly still an issue even today because
of legacy apps ... usually, but not always, in the form of apps that
want overlays. (Maya comes to mind.) Luckily, when the 8 bit visual
isn't the default RENDER can just stay out of the picture.

The most challenging situation we are likely to run into is when there
is a legacy app that needs a pseudocolor visual as the *default* visual.
Usually such an app wants a lot of free colors to play with. (See
problems in XFree86-4.2 when RENDER ate up all the colormap entries.)

Not sure if there is any good handling of that... though since the
root window isn't visible on a normal desktop these days, I suppose
if modern toolkits just defaulted to a non-default visual things could
work fine.

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

Such a restriction seems like it would cause pain for little gain. 
(GTK+ could filter the XListVisuals results conceivably but a less
encapsulated API would have trouble.) Apps need visuals to create 
windows ... apps can easily pass the visual to GTK+.

And it's certainly possible to have a system where the default visual
doesn't match one of the Cairo standard formats ... so we still have
to handle multiple pixel formats per depth.

[..]

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

Sounds good.

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

As well as the problems mentioned above, there's a simple reason why
passing the Visual * in the API is better ... reducing the number of
ints in the API makes the compiler better able to catch errors. 

[On a somewhat related note, I noticed today that the XCreateWindow
docs say you can pass CopyFromParent (which is OL) as the visual ..
looks like a long-ago refugee from the protocol docs]

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/618bb86c/attachment.pgp