[cairo] Redoing the xlib surface constructors

[Owen Taylor]

On Fri, 2005-03-11 at 21:22 -0500, Carl Worth wrote:

> > One possible extension here is to reuse the cairo_xlib_surface_create()
> > name for creating a pixmap and surface at the same time in a standard
> > format:
> 
> Yes, I was hoping we could have this. But that's probably just because
> I'm lazy.

One question I have is why you want this. Aren't you always going to
have a surface around for create_similar()? 

I ported one of the Cairo demos to the new API, and in that case, the
function that would have been slightly useful was
cairo_xlib_surface_create_for_visual()

> > cairo_surface_t *
> > cairo_xlib_surface_create (Display        *dpy,
> >                            Drawable       *drawable,
> >                            int             width,
> >                            int             height,
> >                            cairo_format_t  format);
> > 
> > (You have to pass a drawable in here because XCreatePixmap needs
> > it for the screen. Or we could pass a screen number instead, which
> > would make the prototype a little less confusing.)
> 
> Oh, bummer. The Drawable argument is both confusing, and chips away at
> some of the convenience here. Could we do something lame and just make
> it use the default screen, (since convenience functions need not be
> perfectly general) ?
> 
> > I don't know what to do for the planned 
> > 
> >  cairo_t *cairo_create_for_* 
> 
> Yeah, I'm still trying to think of a good solution here.
> 
> >  cairo_create_for_xlib_pixmap_with_visual()
> > seems pretty excessive, for something (using Xlib) which is already
> > pretty darn verbose. Maybe just skip them?
> 
> Skip them in general, or just for Xlib?
> 
> The problem that the cairo_create_* convenience functions are trying
> to address is the pain of manual object management. Without them, the
> user must manage two objects, (a cairo_t and a cairo_surface_t), and I
> really want to have things like the tutorial full of single-object
> drawing code.

I meant just for Xlib (and in other similar situations.)

I already think that these are somewhat special functions ... that they
only make sense for the C binding. They are inherently pretty nasty
oo-wise because they are surface_t subclass specific additions to the
cairo_t API.

Just to throw it on the table, but not as a real recommendation, the
float/sink model of GtkObject was added to solve a problem much like
this ... to allow writing:

 gtk_container_add (container, gtk_label_new ("Hello"));

The way it works is that the GtkObject has a "floating" flag ... objects
are initially created floating flag. gtk_object_sink is

 if (object->floating) {
    object->floating = FALSE;
    g_object_unref(object);
 }

So, to "adopt" an object, you call gtk_object_ref(object); 
gtk_object_sink(object); ... the first "adopt" call takes over the
initial refcount, subsequent calls are no-ops. Containers adopt their
children. Language bindings adopt the objects they create.

The advantage of this scheme is that the normal case is simple from
C, and it drops out in language bindings with memory management.
The disadvantage, and why I wouldn't really recommend it here is that
that the "complicated" case in C becomes hard to explain.

Another possibility would be to add a C language convenience function
for cairo_create(surface); cairo_destroy(surface); say, 

 cairo_create_and_own (cairo_image_surface_new (CAIRO_FORMAT_ARGB24,
                                                100, 100));

> As for the argument that Xlib is nasty-verbose anyway, don't forget
> that Keith came up with a working cairo-xlib-using program that fits
> (readably!) on a single slide.

I haven't seen that. So maybe I'm just a really bad Xlib programmer. :-)
But my general take is that while you might be able to get something
that quickly, a program that is in any way "useful" - handles resizing,
double buffers output, sets a title, sets a minimum size for the window,
is a couple pages long.

[...]

> PS. And just to demonstrate that lack of clue again, we really will
> need colormap, right? I know you explained why to me before, but I've
> forgotten again, and I still see it being ignored in the code. (I'm
> not actually questioning its place in the API, just curious to be
> reminded what it is I keep forgetting.)

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.

Now, RENDER really doesn't handle monochrome drawing at all, whether
indexed or not. It's all tied to three-channel colors. RENDER doesn't
have any provisions for direct-color visuals. And RENDER's handling
of pseudocolor is crude, at best.

We could do a lot better than RENDER for the non-RENDER code path, by
by, for, pseudocolor by creating a client-side 24bpp buffer, rendering
to that, and dithering down when writing to the screen, but the utility
of that isn't clear to me. Producing *good* results for pseudo-color
means application level intelligence for what colors should be
allocated and what dithered. What's the background that needs to be
drawn with a solid color? What's the image that should be dithered?

So, I'm not going to put up much of a fight if we just make Cairo
(and thus GTK+-2.8) *require* a true-color visual. Some people will
complain, some people may even refuse to upgrade to GTK+-2.8 because
of it, but, honestly, I don't expect Cairo to perform usably on hardware
old enough to have only pseudocolor.

(I think it's been about 10 years since 16bpp became reasonable to
use on the lowest-end new hardware. 800x600x16bpp just fits into
a 1M frame buffer. So, think Pentium-100 class CPU, 16 megs of
ram to go along with that. Even when I started working on GTK+
in 1997, the main demand for pseudocolor was people running 8/24
displays on older workstations where the 24bpp visual was *slow*.)

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/20050312/952da46d/attachment.pgp