Re: RGBA Colormaps in GtkWindow

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

Just subscribed to follow this thread, Hello Owen!!! I'm Cimi!

 

> On Fri, 2008-05-30 at 18:33 +0200, Giuseppe Fuggiano wrote:
> > Hi all,
> > 
> > I am working on a patch to make GtkWindow to use an RGBA colormap, in
> > order to add trasparency to each GTK+ application to make possible doing
> > fancy things by themers and artists, but not only [0].
> > 
> > Actually, after some tests we discovered that not all applications are
> > really ready for this change.
> > 
> > If an application uses a tray icon like XChat or Pidgin, it crashes
> > because of an Xorg badmatch.
> > 
> > Months ago, Ryan "desrt" Lortie proposed some new specs for tray icon,
> > that was accepted [1], but not implemented yet.
> > 
> > Also, some developers would like to have an xsetting to control the
> > colormap, some others (like Owen Taylor) would like an environment variable.
> > 
> > I'd like to understand better the tray icon issue to try to fix it. Is
> > there anyone could help me in that sense?
>
> I think this issue is both a lot simpler and a lot harder than you are
> making out:
>
>  - The status icon issue is *only* an issue between GtkStatusIcon, 
>    the tray icon protocol, and gnome-panel. It:
>
>     - it can be worked around in the gnome-panel by creating a wrapper
>       window if it detects an icon with a non-matching visual
>     - it can be avoided  by simplying making the window for
>       GtkStatusIcon never use a RGBA window independent of your setting.
>     - it can be fixed properly by extending the tray icon protocol 
>       to declare whether the tray wants RGBA icons or not. Ryan's
>       proposal is workable, though I would do it a little differently - 
>       put the visual (or colormap) ID in a property.
>
>   - Once you fix the GtkStatusIcon issue, you need to test a wide
>     variety of apps (especially less native ones like Firefox, 
>     Adobe reader, etc.) to make sure that using an RGBA visual doesn't
>     cause other sorts of crashes or misbehavior.
>
>     If it does cause crashes, you need to investigate those crashes.
>     If they can't be worked around, then we'd need to make apps declare
>     window-by-window that an RGBA visual is OK - a rgba-ok property
>     on GtkWindow, so to speak.

Firefox seems to work fine, (as far as giuseppe told me), I tested Acrobat reader and it crashed (I have installed just for the occasion since I always used evince :) ). Maybe Acrobat should force RGB in the code before realization.
Other applications seems to work just fine, only a problem on rhythmbox with the embedded window, but I should try again with a better patch (I was using LD_PRELOAD with a function that forces rgba colormap overriding gtk_init(), a dirty hack).
 

>   - If the tests are successful, at then point, what you would need
>     to do is add a *style property* for GtkWindow that says that 
>     the theme wants an RGBA window.
>
>     Despite the theme wanting an RGBA window, it might not get it - 
>     you can only use RGBA windows if a compositing manager is running.
>
>   - You'll need to extend GDK to give notification when a compositing
>     manager starts or stops .. something GDK doesn't have currently
>     as far as I know.
>
>   - 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.
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).
Read below about realizing/unrealizing

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

> That's basically the program that would need to be followed. Fooling
> around with environment variables or XSETTINGS is pointless.
>
> - Owen
 
I'm just worried about Xvideo, rather than realizing stuff. But I'm sure that by the time we start setting RGBA colormap we will see all the issues and we will start fixing them. It's the time, also because someone is planning gtk+3.0 and I'm sure it should be prepared to manage this kind of things. There are a lot of applications that are coded in a wrong way, because they were programmed thinking about that RGB is the only available colormap: abiword for example is using cairo_clear and this will result in some transparent widgets, but it is time to fix all that crap! :)


Cheers
--
Andrea "Cimi" Cimitan - <andrea cimitan gmail com>
Website: http://www.cimitan.com
Murrine: http://murrine.cimitan.com
GNOME Developer: http://www.gnome.org