Re: RGBA Colormaps in GtkWindow

["Andrea \"Cimi\" Cimitan" <andrea cimitan gmail com>]

2008/6/1 Owen Taylor <otaylor redhat com>:

On Sat, 2008-05-31 at 02:52 +0200, Andrea "Cimi" Cimitan wrote:

[...]

>          - Now you have another issue to deal with: if a compositing
>         manager
>            stops or starts or the theme changes, then you might have
>         to change
>            a GtkWindow on the fly from RGBA to non-RGBA. This means
>         unrealizing
>            it and realizing it again. You need to do another around of
>         testing
>            similar to the round above to make sure that this won't
>         cause
>            problems for applications.
>
>
> No, I *hope* you're wrong (even if you know this topics billion times
> better than myself :-) ).
> As far as I know RGBA is independent from the compositing manager:
> RGBA is available if your X server is running with the composite
> extension (or the parallel of Quartz, since in OSX
> get_rgba_colormap(screen) returns a working rgba colormap). So you can
> have a RGBA colormap with fluxbox, openbox, or metacity *without* the
> compositing. And you can run windows without any issue, example:
> gnome-system-monitor is using a RGBA colormap, did you see any issue
> enabling/disabling compositing? no.

Well, yes, and no. The way it works is that if you use an RGBA window
that window will always be composited, even if you don't have a
compositing manager running. The compositing is done by the default CM
inside the X server.

This will significantly change the performance profile of the
application in good ways and bad ways:

 - There will be no exposes on the window (good)
 - Hardware acceleration on the window may be disabled
 - The window may be forced out to local system memory
 - More video memory may be used

Whether the net result is positive or negative is going to be hard to
say, and will depend greatly on the hardware and software of the system.

> It is *ready*, but the alpha channel should be pure black if you try
> to use it, but you won't of course :).
> I have written a Gtk+ engine that works as follows: 1) it checks if
> the screen has a rgba colormap, 2) if the window has a colormap too.
> finally, 3) if both are true AND 4) you're running a compositing
> window manager (gdk_screen_is_composited()) 5) then it draws using the
> alpha channels.
> In that way you'll *NEVER* have any black pixels, and any crashes
> (keep using since february).

I think this gets at the important thing: we should not be triggering
application problems at handling RGBA visuals when the theme is taking
no advantage of it. If I start up with GNOME desktop with a simple
theme, I should get an RGB colormap.

Once you say that, you either have do the unrealize/realize thing, or
you have to restart logging out and logging back in again to switch to a
fancy theme.

But isn't too complicated to unrealizing/realizing?
Since the system doesn't change (and if you change your system you need to reboot in order to upgrade your video card :) ), I don't think it's a big problem having to restart GNOME in order to accomplish the new behaviour.
It's important to make this a realtime change (with dinamic realizing), but I would put on a lower priority for the moment, what do you think?
Also, as said, in my point of view the variable/xsetting should be set to FALSE by default until we reach to fix the dinamic realizing stuff

[...]

>            In particular for this, you would want to test out
>         applications that
>            embed OpenGL or Xvideo within then.
>
>            If there are problems, then again, you would need a
>         GtkWindow
>            property (unrealize-ok) to declare that it is safe to
>         unrealize
>            and realize the window again.
>
> Following the same topic above, I have tested a lot of applications
> running in RGBA: when you switch between a non-composited window
> manager to a composited the windows acquire immediatly the
> transparency *without any issue/glitch*! Works great, really.
> So you don't have to unrealize, since applications keeps working great
> and opaque also with a RGBA colormap under a non-composited window
> manager, and if you switch you don't have to bother against those
> realizing stuff (see gnome-system-monitor, it works flawlessy).
> The only issue you may have is that RGBA must be assigned _before_
> realizing, as you know, but by the time you get it you don't mind
> about unrealizing to get plain RGB. This means that the applications
> must read the xsetting/variable _before_ realizing (gtk+ must do)

I would be shocked if there was ever a checkbox in GNOME that said:

 [X] Enable alpha-transparent themes (may break some applications)

RGBA visual usage needs to be done automatically based on the needs of
the theme and the applications and it needs to be done in a safe way.

- Owen

Agree.

-- 
Andrea "Cimi" Cimitan - <andrea cimitan gmail com>
Website: http://www.cimitan.com

Murrine: http://murrine.cimitan.com
GNOME Developer: http://www.gnome.org