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)
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.
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.
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();
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.
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
Have you tried one of the VNC alternatives? Take a look at Tight VNC. There are others... even some implemented in Java. Take a look at Workspot In particular, try out the demo to see what the performance is like on your net connection.
STeveIf 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
There's even a Palm port of VNC, so I doubt it would need quite a lot of a Linux system on the terminal end. If you want to waste time squeezing it down to the bare minimum, I'd think you'd get a working Linux setup with VNC in about 1-2MB of disk space, depending on modules you need etc.. Look for DirectVNC for a VNC client that works directly on the Linux framebuffer without the need for X.
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.
Why is this in science and not in developer?
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
IANAL but im pretty sure no site would bring legal action against slashdot. All they do is link to an article.
Slashdot - The one stop shop for procrastination
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.
Yet many people used Windows 3.1, because it was such an improvement over what had come before
Windows 3.1 was such an improvement over DOS for PCs and compatibles only. I had an Amiga: preemptive multitasking, scalable fonts, multiscreen gui (I could even drag a screen with different video mode), a nice Unix-like command line environment, up to 24 MBs of RAM (for 68000) and up to 4 GBs for later Motorola CPUs, 4-channel 44 KHz sound, blitter and a video chip that could do hardware scrolling, hardware sprites, a mouse, joystick ports...I could access my files directly from Workbench where as I needed to open File Manager under Windows 3.1. I had a flat 32-bit memory model whereas in PCs I was stuck with segments. When I got to Windows 3.1 due to college obligations, for me it was such a backstep!!! Windows 3.1 sucked!!! I imagine that this was the case for Mac owners, too.
By the way, I personally don't think transparent windows are a good idea. Especially when developing software, I don't want to look to source code windows other than that the one I am currently editing, since it is confusing.
But seriously, if you don't want to use OpenGL for your X server, then don't use it. Likewise, if 4 doesn't support your videocard (I heard that some drivers got broken) then use 3.3.6 - anything it breaks your videocard is too slow to display anyway. And if you want games that run on older PCs, buy shareware! People need to use that new hardware for something, and given the choice between getting shiny new hardware and optimizing crap for someone's 486, I choose shiny new hardware. You can always optimize later, and the 486 users should just go use free software so they can compile whatever they need for their own machines.
Oh, and if you have a 386, don't junk it, run FreeDOS!
In the great CONS chain of life, you can either be the CAR or be in the CDR.
This is essentially what Apple is doing with Mac OS X's window manager - using hardware accelerated OpenGL to draw all the translucent window contents as alpha blended texture maps. This requires a video card that can do non-square rectangular texture maps, so only newer machines benefit from this acceleration, which Apple calls Quartz Extreme.
Apple's version of Xfree for MacOS X does OpenGL hardware acceleration, but it doesn't do translucency (presumably, at least in part, to keep Xfree a good step and a half behind the native OS X window manager).
I too am surprised it's taken this long for someone to do it for Xfree on Linux.