Not Just Eye Candy At Freedesktop.org

Jim Gettys writes "While Keith Packard's eyecandy at freedesktop.org, including drop shadows, translucent menus and windows with alpha channels is nice to look at, and in some ways useful, *much* more important is that the same facilities are useful for thumbnailing, screen magnifiers, and arbitrary transforms of applications on their way to the screen, just to name a few of the potential applications. So enjoy the eyecandy, but remember, too much candy can rot your brain. And if you want to avoid fattening your brain, you can come help us make this ready for prime-time, and work off the candy you ate and pitch in at freedesktop.org." For background, see this earlier Slashdot post about Freedesktop.org, and the brief description below.

An anonymous reader sums up this effort to revamp X: "The new X server features full support for transparency, and has window-level image compositing among other things. It allows applications to present alpha-blended content to the screen. A new X Visual was added to the server. At 32 bits deep, it provides 8 bits of red, green and blue along with 8 bits of alpha value. Applications can create windows using this visual and the compositing manager can take those contents and composite them right onto the screen. The X server project holds sources to build an X server separately from a full X distribution."

Comments

Eyecandy is important :-)

[Space cowboy]

... I mean, look at Apple. They've built most of a business around being cool, sexy, and user-friendly. This is a triumvirate for the company, and with the unix-based OS-X, they'll be expanding into hardcore geek territory as well :-)

I even wrote eyecandy (the visualisation applet) on hostip.info - it's a trade: I show you something pretty, you put in your city. Or not. Your choice, but hopefully the eyecandy helps sweeten the deal :-)

Simon.

alpha blending in x vs wm

[jd142]

Since I can't get to the freedesktop site right now, I'm curious about the speed increase when the alpha blending is done by the X server instead of by the window manager. The one screen shot I did see(only because someone mirrored it) had gnome with semi-transparent windows. I'm not a gnome user, I use KDE and I know it handles transparent windows and menus. But how much faster and snappier will the response be with the transparency done at lower level?

Re:alpha blending in x vs wm

[xcomputer_man]

The issue is not really the speed increase (although yes, it will be faster). The point is that this will give you *TRUE* alpha channel-enabled visuals. What KDE and a couple of other projects like the Enlightenment DR15/16 series have done in the past is a "pseudo-transparency" hack done by grabbing the root pixmap and using it to blend. By using a compositing manager and adding true 32bit ARGB visuals, a window can say exactly how transparent each pixel should be, and the compositing manager combines everything together to produce the final display. Semi-transparent windows are overrated: this gives you a LOT more potential for snazzy effects (for starts, how about shaped windows that have antialiased edges?).

Re:But are they doing it right?

[ArmorFiend]

The article you cite is probably a case of a hardware fast path NOT being used, but being advertised by the API. Thus he was asking for hardware operation X, and getting a generic software operation X, which wasn't hand optimized for his particular options. In that case his hand optimized code might be faster by a lot. Such a case occurs fairly often in graphics.

For a non-speculative example, OpenGL's glDrawPixels draws rasters from the lower left corner, whereas most UIs like to draw from the upper left. You can change it by calling glPixelZoom( 1.0, -1.0 ), but in many cases this knocked the gl driver from 1-1 pixel mapping into floating point transforms (basically it started using software to scale the image by some floating point value). A few phone calls to nvidia, 3dlabs, sgi, and intergraph later, and their drivers started special-casing for a -1.0 y pixel zoom, and our software sped up by a factor of about 1000.

In the far future of Moore's law we will not have GPUs at all, merely CPUs with power to burn. So in that sense I agree with you that hardware is/will-be not needed. Now I haven't done any graphics programming since machines hit 1ghz, so that far future may be now. :)

Translucency vs. transparency, and depth percept'n

[HTH NE1]

I, for one, welcome our new alpha-channel enabled translucent overlords.

It has translucency? I have yet to see that implemented. Everything I've seen so far is only varying levels of transparency. I'm only seeing alpha channel implemented, no options for a scatter channel which would define the degree of scattering of the image as it passes through a foreground image.

Ah, I can't fault you. The site itself regularly misuses the term "translucent". Free lesson: if you can make out details, particularly able to read text, it is not translucent, it is transparent. Transparency is a continuum from completely transparent to opaque. Translucency is not part of that continuum. It is different, like looking through a frosted shower door, where you can get the sense of color and motion, but where details cannot be determined. Photons get scattered by the medium resulting in a loss of perceptable detail.

I'd applaud a system that implemented a scatter channel for true translucency. Trying to read text while other text is showing through it is difficult. A moderate amount of translucent scatter applied would be less distracting.

Now think, what if you could apply a visual blurring to windows that aren't in the foreground/under the cursor? Surely that could help focus the user on a task. (There'd need be some control to allow multiple windows be in perfect focus on occasion.) Simulated depth perception to enhance the window stacking model.

Re:Who is going to build the composition manager?

[AKAImBatman]

I think we need to talk to people from KDE, Enlightenment, Gnome, and all of these groups and as a combined effort build the first and default composition manager.

That's what freedesktop.org is. It's a collaboration between GNOME and KDE to develop a set of interoperable standards. For example, you may have noticed that both KDE and GNOME can use the same ".desktop" shortcuts and that ".desktop" files have completely replaced the ".kdelink" files that KDE used to use. Now if GNOME would come up with some sort of (God forbid) STANDARD on how their foot menu works, we might even be able to automatically install icons. Right now, nearly every distro does something different with the way the foot menu works. At least KDE figured it out and has been standard from version to version.