Next-Gen X Window Rendering For Linux 652
Bytal writes "Seth Nickel, a GNOME hacker, has an extensive treatment of the next generation Linux graphics technologies being worked on by Red Hat and others. For all those complaining about the current X-Windows/X.org server capabilities, things like 'Indiana Jones buttons that puff out smoothly animated clouds of smoke when you click on them,' 'Workspace switching effects so lavish they make Keynote jealous' and even the mundane 'Hardware accelerated PDF viewers' may be interesting."
Comment removed (Score:3, Interesting)
XGL, OpenGL-based X11 Server (Score:5, Interesting)
It's an OpenGL-based X11 server, complete with some screenshots. Apparently, window dragging is very smooth (no repaint events are even given to the apps), and with Cairo and GTK, this really could be the future backend for Linux desktops.
Fully accelerated FBDev across monitors? (Score:3, Interesting)
I'm not losing any sleep over this, but it would be cool. I read on an X board that some people are looking at this, but it's obviously a big undertaking.
Some issues... (Score:4, Interesting)
1) rendering to texture is slow on some GPUs, especially GPUs with limited memory.
2) alpha blending is expensive on almost all GPUs.
imo X needs an overhaul, needs to ditch the legacy crap (lose Xaw for example) and move on. stop interfacing with video hardware like it's 1980.
Yet more eye-candy... (Score:5, Interesting)
A few things that sound useful, like:
That's great and all (Score:3, Interesting)
Re:Battle has already been won (Score:1, Interesting)
This current initiative is no doubt pleasant news for Linux heads, and provides them with a glimer of hope but the fundemental problems with Linux GUI(s) are simply too great for this to help them (it will make them worse) and they need tackling first. Of course it won't get tackled, instead the ever growing tower of graphics library layers in Linux is set to meltdown into an ugly mess anytime soon. Well it kind of has already.
You heard it here first
Re:"Hardware accelerated PDF viewers'' ? (Score:4, Interesting)
Finally? (Score:3, Interesting)
Don't be so condescending to OSS. Prior to MacOS X, the Mac was an OS in the dark ages.
If MacOS didn't gut BSD, it would still be using cooperative multitasking.
Re:"Hardware accelerated PDF viewers'' ? (Score:5, Interesting)
Not necessarily so. Well, only if they use hardware acceleration to do existing tasks that are already being done solely by software acceleration. I mean, how many resources does xpdf et al use really?
However, if they are introducing new eye candy wizz-bang GUI magic, chances are that the hardware requirements (including CPU and RAM) will be much higher anyways - even with suitable h/w- accel compatible hardware. And for course those without the h/w-accel compatible hardware, this would eat up even more CPU cycles for the rendering. I repeat, how many resources does xpdf et al use really?
Re:Inevitable comment about bloat (Score:2, Interesting)
Re:"Hardware accelerated PDF viewers'' ? (Score:3, Interesting)
The next problem Aqua has, is that only a few functions really are hardware accelerated, Fonts for instance still are a problem with no acceleration, overall the rendering speed could be faster.
Where Aqua in its current incarnation really can shine, is in effects where the full hardware acceleration can kick in, which is transparency and shadows. Resizsing windows with shadowing however brings Aqua to a crawl (same goes for x.org xcomposite with shadows)
Dont know if those problems are resolvable with the current crop of graphics cards, but I assume once some rendering stuff, like brezier curves (which is used for font rendering) is moved into the shader level, things will become really interesting.
The biggest gripe I have with Aqua is the missing remote functionality, theoretically it would be possible to stream the PDF drawing functions over the net. That would give a much better solution than plain X directives (which are far too talkative) but Apple does not seem to use it.
Re:"Hardware accelerated PDF viewers'' ? (Score:3, Interesting)
True, but it will be eating more of your GPU cycles.
How does it all fit together? (Score:1, Interesting)
GTK
Cairo
Glitz
Mesa
DRI
But where does the X server (via RENDER?) come into play? What about xserver/kdrive or the new XGl, that I hear rely on just OpenGL? What about games that want direct access to OpenGL?
No repaint events (Score:3, Interesting)
IMHO, no app should be given information about it's environment. The only reason expose events exist is because back in the day there wasn't enough memory to store a complete image of every window - so the apps had to be asked to update parts of the display when they were exposed. Apps interacting with other apps without user intervention is definitely a no-no and is the source of some Windows security holes. I just how when (even IF) an app gets to screen capture itself they don't show other data through the transparent parts. It needs to be pulled from its private video memory and not off the screen. The user of course should be able to take a screen shot, so either the window manager needs to have special privledge or it needs to be integrated into the server. I think the special privledge is consistent with what exists today.
Re:Inevitable comment about bloat (Score:3, Interesting)
Well, I'm going to get needlessly nitpicky here: Any time Eye Candy is being triggered by something happening, it is Visual Feedback. One of the most useless bits of eye candy I can think of is the Windows Start Menu fading in. I have no use for it. It's pretty, but it interferes with my productivity. (Just as you mentioned...) You have to understand, though, that it is still providing Visual Feedback. It's giving you a moment to let you know something has appeared on the screen as a direct result of pressing the Start button. The benefit doesn't, for me, outweigh the cost. But it's still there.
Anyway, I'm not shooting down your point, simply nitpicking a detail of it.
Re:Almost (Score:2, Interesting)
Not to smack the OSX hornet's nest, but...
Linux needs to do far more than get to the OSX level if it wants to hold a candle to the Avalon plans Microsoft is not only putting in Longhorn, but WindowsXP.
The only things OSX is doing that Windows2000 didn't do is the off-screen rendering and having a more extensive vector based drawing capabilities ala Adobe.
Avalon is not only a whole new UI system for the OS and applications, but it is a simple development model that will let 10 year olds create 3D applications that look awesome. Easy programming will be a key part of the Avalon in Microsoft's Windows. DO NOT UNDERESTIMATE MICROSOFT IN THIS AREA. You will see awesome 3D applications and true 3D implementation that is functional in simple Visual Basic apps written by novice programmers even. Mark my words. (Letting things like Kylix die on Linux is another mistake everyone here is letting happen and should also be addressed, but is off topic for this post)
Additionally, OSX uses very few GPU hardware accelerated features in the UI and is only a 2D accelerated UI. It is not a 3D UI, you can place cameras, lights, etc in a application like you can with Avalon, they are night and day comparisons at this point.
With that said, it is sad that Microsoft's UI Beta is far more advanced that even what Apple seems to be planning or providing for its users, Apple is supposed to be the Graphics leader, and once again they are still playing catch up.
As to Linux, and the open source world, we need a revamp on a mass scale. A new X11 system that is hardware integrated expanded OpenGL and a whole Multimedia API like Microsoft's DirectX.
Someone above mentioned that things are harder on Linux and Windows, but actually they are right now easier on Windows, as developers, even hard core gaming developers can write to DirectX for all aspects of input, and audio and visual output and not have to deal with specifics of the user's hardware. This is something Apple also needs to implement, but they never have had to since they always control the hardware, but as their hardware expands with different features, it is something Apple needs to consider as well.
Hardware abstraction is a good thing, especially when dealing with high performance hardware like GPUs and Sound Cards that have built in rendering capabilities.
Linux, Open Source in General, and even Apple need to think past just getting by with OpenGL, and have a full consistent API if we are ever going to see a lot of great UI enhancements to these OSes, and offerings of Games that are easier for developers to port and create for the OSes.
Just like the Xbox, half the reason of its success is the ease of development for the games, using a DirectX interface made it super easy for Windows game developers to flip out an Xbox version and vise versa. It also made it easy for developers to take a game for the PS2 or GameCube and drop it into the standard DirectX programming on the XBox and Windows to create games for both platforms.
With DirectX the ports to the XBox and Windows became easy and routine as they only had to learn to port to DirectX, not a mass array of hardware. Which is where we are now, even with OpenGL and the driver situation in the open source world.
Ok, kind of got off on a rant, but we need to encourage the original developer and our open source leaders need to sit down and design a system that if far beyond OpenGL and the standard *nix models that are outdated for pumping mass amounts of audio and visual data to the screen and even across networks.
We also need to slap Apple in the face to get their attention. Them having control of the hardware is GREAT for them and their OS development, but it DOES LITTLE for gaming developers for OSX or for application programmers that want to add real 3D interface elements to their applications.
Re:"Hardware accelerated PDF viewers'' ? (Score:3, Interesting)
Re:"Hardware accelerated PDF viewers'' ? (Score:2, Interesting)
Motif? Hell, that functionality was in twm(1). It's always been there. Multiple desktops were the next step of course, and that's why I run ctwm(1). Maybe there's something better around the corner, and maybe not.
Re:Uhm, E17 anyone? (Score:4, Interesting)
Enlightenment is sort of hard to categorize. I believe they refer to the whole suite as a "Desktop Shell". That is, they offer more than a Window Manager (a suite of high-powered libraries, a launcher/panel, desktop effects, file browser, etc.) but less than Gnome or KDE in terms of a desktop environment (which include full cross-platform toolkits, application interoperability, central configuration, random daemons, etc.) The goal of E17 seems to be creating an amazing user desktop experience, but the goals of the next-gen rendering are mainly a superset.
What Seth is talking about is the fundamental application stack for rendering windows and widgets on the screen. Right now, the printing usability situation is really bad. This is one area where I think Windows really gets it right. Adding a printer is quite easy, and your document always looks like what those "print preview" pages allege it will. Currently, there's little guarantee that the printed output of your document will match what you expect it to be, because there's two different rendering pipelines for screen versus page. This is what Seth is talking about. Unless they want to get even more ambitious, the Enlightenment project has nothing to do with printing.
By itself, E17 may be able to give your windows shadows or fake transparency, but a full compositing manager + hardware accelerated backend will allow true alpha blending, fast updates and fun live animations like OSX's genie. Note that this extensions can be easily used by E17 as well, but are really impossible without them.
Finally, the toolkit integration is probably the most exciting. I know E17 is sporting a basic toolkit library itself, but that's probably because they want tight integration between native E17 apps and the WM. I personally think this is the wrong move, because they're probbaly not going to be able to create a fully-featured and cross-platform toolkit like GTK+. (Hence, not many application developers are going to use EWL.) A GTK (and eventually, QT4) application will be able to rely on a sophisticated drawing level (Cairo, instead of Xlib), which will allow all of its applications to be rendered nicely, allowing blending and more free-formed widgets. gDesklets and the like are just the beginning.
Imitation is the higest form of flattery (Score:2, Interesting)
Re:"Hardware accelerated PDF viewers'' ? (Score:3, Interesting)
This box is dual-booted with WinXP SP2. Under WinXP if I open a PDF with the latest version of the Adobe Reader, the processor jumps to about 30% usage from 0%-1% usage. While that is not "great", it is still much better than the huge spike I get on the same system under Linux. As a major user of Linux, I personally would like to know what the huge processor usage is from? I actually use Linux with the official NVidia Linux binary and an NVidia GForce 3 TI 500 (this card still kicks butt and can play the latest Doom fine), so I get pretty good 3D excel.
On X "bloat" (Score:2, Interesting)
Re:"Hardware accelerated PDF viewers'' ? (Score:3, Interesting)
Well, my suggestion is to combine together multiple desktops with something like this [stuff.gen.nz], which allows you to group and control windows elegantly, and potentially in complex and useful ways. If groups could, for instance, hint to the taskbar to group their entries, and applications were capable of hinting to the WM whether to create a new group for its subwindows... well, then you'd have some very useful new window control/management tools available to you.
Jedidiah.
Re:"Hardware accelerated PDF viewers'' ? (Score:1, Interesting)
If xpdf pre-rendered the pages the amount of processing time needed at any one time would be reduced.
I'm not certain how useful it would be to render books with the GPU.
And your video card doesn't play the latest Doom fine, unless we have vastly ideas of what fine means. I know, I have one just like it and it's pretty lacking.