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.
If I'm not mistaken, recent Windows use the 3D acceleration to draw all 2D operations, which means they can accelerate everything. I'd love to see XFree do the same thing. Really, this is more than a nice hack.
The guy is working hungry and with poor resources, and you throw rocks in his webserver! Thanks slashdot!
This is being discussed here.
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.
Mirror List
Mouse powered Chips, Open source Processors and Lego
More power to us? How? In what way? I would hardly call translucent windows and shadows "more power", it's just eyecandy and doesn't improve my productivity.
Quartz Extreme uses OpenGL acceleration for window compositing, but the actual drawing inside the window is still rendered in software.
Heck, when it comes to raw drawing speed, Quartz is actually slow.
I've been puzzled by transparent/translucent window fluff.
What is the point? Other than chewing up graphics card cycles.
If you have one window and a black background then super. Kinda just like what I have now. But if you are trying to code in vi, and that window is over slashdot, and that window is over irc you can't see anything!
Please tell me what I'm missing.
For those who keep talking about how windows has been 3d accelerated for ages or whatever, that's untrue. Windows did not care about 3d acceleration before Win2k, and I *believe* it still uses all 2d rendering for the new layered window stuff in 2k/XP (but I could be wrong - I know that there is a hardware accelerated alpha blit function available on every windows platform from 98 on). However, the new layered window stuff *does* buffer windows in offscreen 'textures' instead of rendering them directly to the display. But as anyone who's tried resizing a large transparent window knows, it's nothing to write home about.
Aqua, if memory serves, stores all windows and bitmaps in offscreen texture buffers, does almost all primitive rendering with hardware primitives, and then composites it all onscreen using quads (or triangles, whatever) and applies various rendering effects to it.
This system seems to simply buffer individual windows in VRam, render to them in software, and composite them in realtime using the hardware, instead of just rendering everything directly to the front-buffer. Unless they get most primitives rendered in hardware (especially bitmaps/icons), it's going to be ass-slow.
Just my 0.02c.
using namespace slashdot;
troll::post();
Another project (with admittedly a different aim) that is trying to bring exciting and modern desktop features to the masses:
http://www.directfb.org/xdirectfb.xml
Wouldn't it be nice if there was a consensus project for UNIX/Linux graphics that could integrate and manage the work of all these many people? Concentration of effort, rather than dilution?
if this means adding an opacity slider to Metacity ;)
Would the Window Manager take care of the opacity of a window, so it was either all transparent or none, or would this be something the application involved did, to make parts of the app transparent and other parts solid?
Transparency is nice, I'd like to have all my popup menus transparent but not necessarily their parent windows, I think things are going to get complicated fast perhaps though!
The problem with slashdot is that most of its users were bullied and stuffed into lockers as kids!
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===
Well actually I use it in OS X all the time. You need to toy with the levels enough to get it just right, but its actually somewhat useful to cascade a couple of windows, one with a man page or a browser showing help text behind a shell that you are trying out the command in. Not essential, by any means, but useful enough to miss when you can't do it.
-- Oh Well
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
I have experiemented with translucent terminals in Mac OS X and found that things are less readable on the whole. Maybe the trick is in the user interface. Since I often find myself minimizing, hiding or otherwize moving a terminal window out of the way, maybe the solution is to have a key combination that makes an app window translucent while they key is held down? This might be more useful to me.
-- Solaris Central - http://w
This is the way to go for eyecandy, using the Hardware, which lies unused when in a 2D session. I've been waiting for something like this quite some time now. Good thing it's here now.
But there's still work to do. Note that the windows are translucent all across, borders and all.
We suffer more in our imagination than in reality. - Seneca
If you read the page then you'll notice that the excitement isn;t really about a quick hack to get the abysmal transparent windows working, it's about an OpenGL X-Server.
This would mean some of the drawing done by the GPU instead of the CPU.
What's the point?
The basic need is that, well, it needs trying out!
It's easy to say "oh, it will never work" but that's nto really true until someone can show you a well crafted OpenGL desktop and it doesn't work.
I hope it works because for the most part my expensive graphics card pumps out a 2d desktop.
There are places where the networks are not touching,and there are places where they are-Boeing's Lori Gunter
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.
Anyone looking at the framebuffer device as salvation is barking up the wrong tree. Yes, its direct to hardware, but it's slow as molasses when there's anything happening on the screen. Try running a console-intensive app on a fbconsole and watch the latency of all your apps go through the roof. I can't even play an MP3 when the framebuffer is busy, and I have a top-end system with optimized software.
XFree86 has direct-to-hardware rendering, it has DRI and MITSHM. Granted it uses a few more megs of memory than I'd like it too, it's our best bet for 2D performance out there. It really is quite good, I think a lot of the desktop environments need optimization (KDE is a bad performer all-around, IMO).
The framebuffer exists for three reasons:
1. Simple to program for.
2. Needed for 68k and most PPC machines (no native console mode)
3. Platform Independent.
it doesnt:
1. Perform well enough for casual use.
2. Play well with others.
3. Run X programs without the overhead of X anyway.
"Sometimes, I think Trent just needs a cup of hot chocolate and a blankie." -Tori Amos on Nine Inch Nails
There is a fundamental limitiation to modern graphics displays that limits the usefulness of translucent windows - the lack of different accommodation depths.
Consider driving along the road as it starts to rain. Normally, you are looking downrange - your eyes are focused on infinity (as far as your visual system is concerned). The rain drops on your windshield are forming an image on your retina, but it is out of focus, and so is easier for your visual system to ignore.
Should you want to look at the raindrops (to evaluate whether the rain is sufficient to require you to change your driving pattern), you shift the focus of your eyes. Now the raindrops are forming a clear image on your retina, but the road is not - now it is the road that the visual system can ignore.
So, to extend this to a computer display - at a minimum, you would want to employ some form of blurring on the windows in the background as well as reducing the contrast. For this, a 3D card with motion blur might work without too much added work.
But the second thing you need is a good, quick way to shift focus from window to window. If the back windows are fully obscured by the forward windows you cannot just click on them. You cannot just shift focus - the system has no feedback where your eye is focused. As a result, you have to minimize the forground window, or have a "send to back" button, or something like that, and you still get into the "nope. Nope. Not you. Nope. Nu-uh. Nyet. Aw, c'mon!" mode.
www.eFax.com are spammers
here: http://www.stupendous.net/mirrors/transluxent/
;)
In case of slashdot effect
I use them on OS X and having a terminal/vi and a IDE (e.g. Project Builder) visible at the same time (terminal over source editor) is _really_ useful.
It's also useful when Googling to fix system problems (web browser underneath, term on top) or to diganose system problems on multiple hosts (with a large number of overlapping x terms).
I have no problem seeing though 3 levels of terms, or reading translucent terminals. The exact level of translucency, the color scheme and not having a very distracting desktop background are quite important factors though.
I'm all in favor of other people doing things like Quartz Extreme in the open source community, first of all, because it gives Apple something to compete with, and secondly, because it might do things that Apple didn't think of. In the latter case, users can benefit from the free version, and perhaps Apple will try to incorporate those same innovations back into Quartz Extreme.
"Give a man fire, and he'll be warm for a day; set a man on fire, and he'll be warm for the rest of his life
Don't you mean the male human brain? :)
You seem to only see one side of the picture. Try doing a tutorial on some webpage while using a terminal to follow the instructions. Its not just cool to look at, it is functional to see what you are doing below the terminal window. On a small monitor, you don't have to move the windows every time you want to read a line, while working.
Its kind of funny, I'm reading a lot of comments like yours. Which is fine, of course. But there is a sort of big push right now for just this sort of thing on Linux desktops. Eye candy, it seems is underrated here?
As a user who has been using the Linux desktop for about 4 years now I'd have to say this is a very exciting project. You should take a look at kde-look to get an idea what types of eye candies are being kicked around. I've been using translucent aterms, Convectivea crystal icons and the Mosfet's KDE liquid module for quite a while now, I love it.
Btw, check out Karamba, its a new KDE extention that suports (fake) transparency, lots of fancy do-dads and themes. Beefs up the candy factor (and some functionality!). Might as well look good if your going to have to use it.
Last one! Check out Slicker. Its a collection of utilities which provide an alternative to KDE's kicker, and looks good. I don't know about you, but I got tired of looking at screen shots of OSX.
Quack, quack.