Comment 13 for bug 195929

(In reply to comment #12)
> I think the way to go would be to extend the engine API to provide additional
> entry points that take cairo_t parameters. I don't know how practical that is.

There are some 20 darwing functions, but only 12 slots left to add more funtions to GtkStyle. So it is not possible to just add a second set of functions to engines.

> > The problem with the GtkEntry is that it consists of two X windows (one around
> > everything, and one for the text area). Both of these windows are filled with
> > base[NORMAL], ie. the background color for the text. So to get the rounded
> > look we need to fill the background with the correct color.
>
> It seems to me that in this case the outside window should be transparent
> instead of being prefilled with the text background color. Maybe that doesn't
> make sense for a GdkDrawable API but it would make sense for cairo_t API.
>
> Another option is that using cairo, it is possible to draw with OPERATOR_SOURCE
> or OPERATOR_CLEAR and "knock out" some pixels, making them transparent or
> translucent where they're currently opaque. So it would be possible to actually
> make the area outside the rounded border transparent even if it started off
> with a solid color.

GTK+ does not use windows with an alpha channel by default. Also wouldn't this need a working composition manager? What about older X versions and the different backends (directfb, windows, osx)?

> > The progress bar case would may be easier to fix. The problem here is that
> > GTK+ caches the bar (without text) in a server side pixmap. I do not know
> > what the reason for doing this is, however it means that we need to fill the
> > background to prevent displaying uninitilized memory.
>
> cairo would fix this again because you could cache an RGBA surface instead of a
> pixmap. (Actually the RGBA surface would be an XRender pixmap.)

Hm, using an RGBA pixmap should work, yes.

> So it seems to me that GTK+ should move towards a cairo-based API for theme
> engines, then these problems can be fixed on the GTK+ side and we can have a
> better interface for our needs too.

True, that would be nice (though it would not fix these kind of problems for free, would it?). However, while breaking the engine API is possible in general, I don't expect it to happen very soon.