[cairo] Redoing the xlib surface constructors

[Keith Packard]

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

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

Render has several settings to change the size of the color cube allocated 
from the default colormap, from no colors (black and white only) to 
filling the whole default colormap with a cube.  The default setting is 
(surprise) a compromise designed to let Motif apps work.

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

'sick' is in the eye of the beholder...  For text and line-graphic based 
applications (typical of the Motif era and before), things will look "just 
fine".  For graphic heavy applications, it's gonna hurt.

Like I said, dithering isn't in Render because no-one has bothered to make 
it happen; if someone finds a giant customer base demanding reasonable 8bpp
performance, then perhaps that will change.  I'm not holding my breath 
though...

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

The ideal solution here would be to create a pseudo-display which 
presented the pseudo color visual as the default.  I've got a pseudo-root 
extension which could do that easily enough; integrate that into the WM 
and you could reparent the apps out of the pseudo root and back onto the 
regular desktop.

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

The gain is in reducing the complexity of the API and implementation,
worth it to me because I don't need to support existing apps, but perhaps 
not worth it to you as Gtk+ exposes enough of the X horror to let apps do
things which don't match this model.

That leaves us with just a visual, which seems more than reasonable to me.

> [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]

Oh, that works, but I'm not sure we need support it in cairo.  Or, if we 
did, it could mean the 'obvious' visual as discussed above, but that seems 
like a recipe for disaster.

-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/5de39356/attachment.pgp