Comment 11 for bug 195929

(In reply to comment #10)
> > This is a lot an issue that is a lot more complex than just "using
> > transparency instead of drawing the window background color as part of the
> > widget".
>
> Sure.
>
> > We *need* to draw the background color in a lot of cases (GtkEntry,
> > GtkProgressBar)!
>
> I believe you, but why is that?

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.

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.

> > I don't want to go into too much detail here, but I would not be suprised if
> > this is not fixable in GTK+. (I have not investigated this possibility too
> > much.)
>
> That depends on how much you are willing to change GTK+ or the themes, I guess,
> since it's possible to design themes that don't show these problems.

As just mentioned, the core problem is in GTK+. Both the back buffer, and the second window should not always be necessary. The problem I see is that the API/ABI stability might be broken in some cases. (Or eg. themes get broken if the background is not filled with base[NORMAL] anymore in the entry.)

> > So this means the only way to achieve the correct behaviour would be to
> > somehow work together and hint the engine/theme that filling the background
> > is not necessary.
>
> Interesting. Can you say more about how that might work?

Not sure. It may work by attaching extra data to the widget. Or having a certain widget path.

> > (Hm, I shouldn't missuse this bug to complain, but I do not like mozillas GTK+
> > emulation stuff in some ways. For example you could at least give the
> > GtkWindow or the GtkFixed a name with gtk_widget_set_name to make it possible
> > to create sane special cases for mozilla.)
>
> That's a good idea, but I would call it something more like "HTML" because
> Webkit/GTK+ is using this code too.
>
> What other suggestions do you have?

Not sure right now. I'll need to think about the problem again, and look at the mozilla code.
Oh, one thing that strikes me as rather weird is that IIRC a GtkInvisible is used to get the default colors for the HTML page. This could be handled better by using this "HTML" container widget (whatever it is).

> One thing I really want is the ability to pass a cairo_t directly down to a
> theme at least for those themes that draw using cairo. Right now when we have
> to draw a widget with rotation or scale, or to a non-X surface (printing), we
> have to use horrible hacks involving temporary pixmaps. When the widget is
> partially transparent the hacks are even more horrible.

Yeah, I remember seeing the GTK+ bug.

Not sure how this may work. I do not know that much about GDK internals. This would either require changing the engine API, or special GDK code that is able to pass the cairo context trough to the engine and handle drawing to the X window correctly. (Which I imagine would get really nasty if both cairo and gdk API are mixed.)

Another way, working around the restrictions in GDK might be to attach the cairo context to the passed in GdkDrawable. However that seems like a pretty nasty hack to me. (The engine would draw on the cairo context, and somehow hint that it did.)