Slashdot Mirror
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."
Do translucent windows sitting on top of video playback work with accepatable speed?
... 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.
Physicists get Hadrons!
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?
Don't get me wrong, if you have fast hardware and are trying to convert grandma from "some other environment" go for it, but for me personally I will take lean, mean, and quick any day of the week.
I Am My Own Worst Enemy
Eww, a whole new server? I hope there's more code sharing against XFree86 rather than less.. it would seem a tremendous waste to have to reinvent and maintain that particular wheel.
Even for someone as renowned as Keith.
- jon
Ganymede, a GPL'ed metadirectory for UNIX
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.
I think thumbnailed applications was stolen from enlightenment which has existed long before os-x.. try again. (It also had transparent terminals before os-x)
Hmm, this looks promising. Now all that is needed is for someone to write either a compatibility layer to bring the XFree drivers over to the freedesktop.org Xserver including GLX compatibility, make the Compositing Manager use OpenGL and eureka we have GPU based compositing.
This is close to the features coming in Longhorn, where the windows are to be considered textures rendered by the GPU.
Now my personal dream is still to see a combination of this and a high level protocol/server in which the applications and window managers send in calls where they ask for things like a button or a menu and include the data, while the rendering mechanism (the widgets) rest on the serverside (allowing for a central repository of widgetsets and almost guaranteed consistency of the UI). Custom widgets could then be implemented as either "server-side" extensions ala the scripts/executables that make up a webapplication or as client side components which are allowed to send drawing instructions to the server. It is intriguing to think about the possibilities of letting each window own a thread and socket connection (as in a modern webserver) to the application so that they can all update their own "scene" concurrently (almost anyway) and then the central compositor/renderer renders these changes from the existing application/windows tree.
A person is smart, people are deeply stupid
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.
Oh, say does that Star-Spangled Banner entwine / The myrtle of Venus with Bacchus's vine?
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.
Actually, from what people at SIGGRAPH kept saying, graphics cards are outpacing Moore's law. If that continues we'll have amazing vector processors and rasterizers with a dinky little CPU telling them what to do.
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.
Javascript + Nintendo DSi = DSiCade
In order to play with this X server, what hardware does one need (i.e. what hardware does the current CVS version support?)
John_Chalisque
You're assuming the only choices are to present 5 commands at a time or to present all commands in one big long list. There are other ways, you can present a screen-full of commands divided into small groups, each group presented in its own section.
Look at real menus in restaurants. Some restaurants have a lot of food choices, but the choices are presented under different sections, appetizers, soups, salads, noodles, etc. Once you find the right section, you can find your favorite food easily...
Now think about those menus that go on for pages, you have to flip back and forth between pages just to find the proper section. Other menus are presented as one big page (double-sided perhaps), to find the proper section you quickly scan the large-type headings and take it from there, it's just as easy minus the page-flipping.
Cascading menus are like multi-page restaurant menus. I'm saying that we now have enough space on the screen to present single-page menus (or perhaps 2-page).
Another example, say you're looking for the shrimp-noodle soup but you're not sure which section it is in. For the multi-page menu, you have to flip flip flip to the soup page, check there, then flip flip flip to the noodles page, check there, and so on. For the single-page menu, you quickly scan for the possible sections and look in each, if the particular meal doesn't jump out at you, you still have all sections in front of your eyes so you can locate another meal that is close to what you want.
This is like the preferences command. You never know if it's under File, Edit, or Tools, you have to visit each drop-down menu in turn. If all commands were presented in a single sectioned page, you'd have an easier time finding it. Furthermore, on subsequent visits, the visual clues of that particular menu help you remember where the preferences command is.
Another example, toolbars became popular about 10 years ago. Why? because, on one hand it was a one-click deal, and the other hand they presented all the commands at once (divided into small groups of course). Their only problem: because of space limitations, they use icons which get to be cryptic. With today's bigger screens and faster cpus, we can pop-up a giant version of the toolbar but with text to make it more usable.
I'd go and participate in E17. Enlightenment as a wm rocks, but E17 looks like it's got all of the desktop goodies + the fine wm.
Judging by the amount of time they're spending, they could probably use the help.
You need to restart your computer. Hold down the Power button for several seconds or press the Restart button.
It actually took into account the stacking of windows, and would draw a shadow that represented the window's "height above desktop" - so a window that was on top of a large stack of windows would have a severely offset shadow, and one on the bottom of the stack would have a minimally offset shadow.
Also - the shadow-casting onto windows beneath also took into account the relative height differences.
The end result was an *amazing* feel of 3d, on a crappy old 7.14MHz 68000. We should definitely be able to do better on today's marvels.
Both POC and GCC can be made to use a garbage collector with Objective-C. That doesn't do anything to fix the incredibly nasty reference counting the ugly OpenStep API has, though.
That said there are a lot of stupid things about Objective-C because of it being little more than a message-passing preprocessor for C. There are no modules or namespaces, so you end up with stupid prefixing conventions. Because the object system is essentially bolted on, you can't program generically except with message passing. Since it only offers message passing, you can't extend operators to work over user types. Selector signatures are supposed to match through the class hierarchy. Objective-C is not type safe.
In fact the only interesting thing about Objective-C is actually not part of the language, but rather an Apple extension. Categories offer a very nice, pragmatic way of modifying existing classes.
There's rather little reason to promote or continue Objective-C as a language. If anything embracing Smalltalk would probably have been better for a productivity perspective. Instead of a half-assed inconsistent Smalltalk on top of C, you can just have Smalltalk. If you need high-performance extensions that's what FFIs are for.
This is true for sharp shadows. But for fuzzy shadows that are being shown here, the correct result from such a diffuse lighting source would be a lighter and wider shadow. It turns out that identical shadows are actually a pretty close emulation because the lightening and widening of the fall-off curve approximately cancel out, and there is obvious speed benefits of implementing them this way.
A simple change to make it more realistic would be to increase the transparency based on the difference in Z. This would improve it far more than changing the width would.
If the "compositing engine" has access to programmable OpenGL shaders there are hacks that can be done that will make very accurate diffuse shadows.