Re: Windows2000 coolness

[Federico Mena Quintero <federico redhat com>]

>  	Is that to be brought to its logical conclusion of, "...and since
>  X does not have an alpha extension, Gnome won't have this feature"?
>  
>  	Is that what Rasterman said about translucent window moves? :)

Translucent window moves as implemented in Enlightenment are a hack.
A very cute hack, to its credit, but a hack nonetheless.  They don't
work properly on non-truecolor visuals or on machines with multiple
visuals.

>  	Forget 'Properly'.  Perhaps we could put some kind of caching
>  engine into Gdk that would pre-compute the translucent stages of the
>  animation and keep them in RAM, and add some kind of 'tainting' mechanism 
>  to Gtk+'s menus and tooltips to expire the cache upon a menu change.  Or
>  even compute the fades on-the-fly.

This does not make any sense.

If you wanted to do fade-in menus, you would need to

	1. XGetImage() the area where the menu is going to appear;
           demangle that into RGB data.

	2. Generate an off-screen image of the menu in its initial
           state.

	3. Composite (2) into (1) with varying opacity levels and draw
           it to the screen.

(1) and (3) are trivial, (3) would be the current Enlightenment hack
for the lack of a real alpha extension in the X server.

(2) is hard.  How would you do it with GTK+'s current framework?  If
you give us a solution, we would be happy to investigate it.

>  	As somebody else has already mentioned, we should accept the fact
>  that this effect will be a resource hog.  It must not be implemented
>  without an option to turn it off.  But for those which have the hardware
>  (and there are many) it would certainly make Gnome the preferable Unix
>  desktop environment.

Doing the alpha compositing is *hardly* a resource hog.

  Federico