Slashdot Mirror
Translucent Windows for X using OpenGL
Anonymous Coward writes "Take a look at this! This guy is working on an OpenGL backend for X. But he needs pizza and some new hardware. He's on a TNT2 for heaven sake!"
← Back to Stories (view on slashdot.org)
Everybody seems to be obsessed with all this "3D-accelerated desktop" stuff but IMHO it's all overrated.
Using OpenGL will not automatically make everything faster. Heck, I wouldn't be surprised if some things become slower. OpenGL is good for 3D stuff, but sucks for 2D stuff. Ever tried blitting in OpenGL? Slooooooooow. And guess what? Most applications use 2D drawing primitives.
The biggest performance bottlenecks are, and have always been: 1) the driver 2) the kernel.
2 has already been addressed (my system flies with these patches; it's even faster than Windows!). The upcoming 2.6 kernel will be amazing.
1 remains a problem. X's architecture doesn't cause the slowness, it's all in the driver! If the driver doesn't implement all OpenGL features then you'll still be stuck with slow drawing speed (or maybe even slower, since emulating OpenGL is slow beyond imagination. ever tried running TuxRacer in plain non-accelerated Mesa?)
Two more uses besides alpha blending that instantly spring to mind:
- scaling (with interpolation)
- color depth independance
without the underlying application having to know about this at all!
Really?! That's great! I'll just go download the sources off a local mirror and install...
Oh, that's right. It's not free. Well, maybe now you understand why some of us are excited.
The guy is working hungry and with poor resources, and you throw rocks in his webserver! Thanks slashdot!
I don't know about you but when I'm reading a webpage, I want to concentrate on the webpage, not everything below it.
When I'm writing a report, I want to concentrate on my word processor, not all the windows below it.
Translucent windows is eyecandy and good for demonstrations, but that's pretty much it. Other than that, they're usability nightmares and harm productivity.
I say make him keep the old graphics card. That's a good minimum level in terms of consumer graphics hardware and it'll ensure the end product isn't bloated if it's useable.
Start pr0n
Enjoy Pr0n
Girlfriend comes into house.
Franticly load word processor to cover pr0n
Scream as you notice you have windows transparent
Girlfriend kicks you out of seat and takes over pr0n viewage!
Wake up
===Sig===
IMHO "ready for the desktop" is a moving target. For goodness sake, Windows 3.1 was once a viable commercial product! Today it would be laughed off the market. If the current KDE desktop had gone up against Windows 3.1 the world would be running Linux right now. Yet many people used Windows 3.1, because it was such an improvement over what had come before.
I think Linux is entering the desktop race at an unfortunate stage. So many people are now so used to Windows that I'm not sure what can be done about it in the short term. IMHO KDE as a desktop environment can mostly stand toe to toe with Windows. But it doesn't matter, because it isn't exactly what people expect.
The number of computer users has exploded over the last ten years, until now much of the technological world is dependent on them. But that also means a lot of people and companies have standardized on one thing - Windows. There's not a whole lot you can do about that - one the decision is made and people are trained, the inertia in the system outweighs EVERY other factor.
We as geeks tend to forget this, but many people want the computer to just do its job and stay out of the way. Which really means "do what I expect". What they expect is what they are used to. Checkmate.
I consider the computer desktop to be a natural monopoly, even more so than things like phones. Phones were only a natural monopoly while there was one way to get a signal to the home, and it involved laying lots of cable. But technology changed that situation, and the people were ready to use it, because it didn't involve any significant change on their part. The monopoly with computer software, however, is driven not by technology but by the USER HIM/HERSELF. There is no solution for this problem based on technology. I know the thought is usually used in other circumstances, but it applies here - you can't apply a technical solution to a problem rooted in people. The monopoly comes from people.
Yes, Linux still has some weaknesses. But compare it to Windows 95, for example, which kicked off the PC boom. Being "desktop ready" is all relative. And in the end, I think worrying about being "desktop ready" won't make any difference, even if we are somehow defined to have "made it". I'd worry about inertia. That's the real enemy.
"I object to doing things that computers can do." -- Olin Shivers, lispers.org
The idea implemented here has more value than the novelty of translucent windows. Because each "window" is actually a texture stored in offscreen memory a window is never actually obscured. No more expose events! No more clip lists. Perfectly smooth window dragging in your window manager. Minimising a window won't cause obscured windows to redraw. It's like save unders but with hardware acceleration.
A little bit of history is required here. X was written back when video memory was very tight: the framebuffer (what you saw) was ALL of the video memory. There wasn't any unused video memory for textures or pixmaps or caching. So obscured windows caused a big problem: what do you do when you unobscured the window? One technique was to store a bitmap of the window as a "backing store". If the backing store is on the X server then it is called a "save under" but it's the same concept. When a region is exposed you'd just draw in the previous contents from the backing store.
Unfortunately backing stores use up heaps of memory. So the preferred technique was to send an Expose event to the application, tell it which region just got unobscured, and the application would redraw the necessary pixels. CPU was and still is cheap compared to memory! This is the technique still in use today and explains why you get messy redraws when you drag a window around your desktop.
For people who are serious about removing all the cruft in XFree86, you could make serious headway by forcing all windows to be allocated with this TransluXent technique. The amount of legacy code you could rip out of XFree86 is staggering. All the clip mask code. All the loops around drawing code. Lots of tests become useless. No more need for Expose events. Also imagine a proper Xshape extension using alpha masks instead of clip lists.
This TransluXent technique is unfortunately only hackery. They've implemented a "framebuffer" type based on cfb (colour frame buffer). This is the intermediate model that XFree86 uses before your video driver gets involved. So even though they get the translucency they won't get any of the potential to simplify the X server. If somebody could implement this idea higher up the chain - say as an extension to save unders!? - then you would make XFree86 a serious contender for Aqua style graphics.
Of course, the downside is that you'll chew up serious amounts of offscreen video memory (aka texture memory). You might need to implement some code that "swaps" unmapped windows into system memory.