2008/6/1 Owen Taylor <[EMAIL PROTECTED]>: > 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 - <[EMAIL PROTECTED]> Website: http://www.cimitan.com Murrine: http://murrine.cimitan.com GNOME Developer: http://www.gnome.org
_______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
