Xorg and Desktop Eyecandy 416
BonoLeBonobo writes "Xorg is going to include a new acceleration architecture which will help desktops to have better eye-candy effects thanks to a better XRender, thus composite, acceleration. Developped by Zack Rusin, a KDE and Qt developper, this new feature should be present in Xorg in September. Porting the existing drivers to this new acceleration architecture should be easy."
When will we have... (Score:4, Interesting)
This will mean more than simply being able to easily take out possibly unwanted cruft out of X packages (stuff like xcalc, xterm, etc). It will be pretty easy to put just the X server libraries and binaries on one computer and the X protocol libraries and applications that use them on another.
I'm sure you could do that now, but it would require a lot of work.
I'll probably be modded down, but.... (Score:3, Interesting)
I think its great that X is getting a universal architecture for this sort of stuff, but I'll be disapointed if Rastermann and others dont have some sort of input in this, mainly because DR17 is showing me how *fast* this sort of thing can be (faster than KDE in the case of DR17 and a 2 second boot-time on my AMD 2600+).
As for applications made using the Enlightenment Foundation Libraries.... wow...! Entice [get-e.org] is absolutely amazing, totally dynamic and animated, as well as mainly transparent, perfect for an image viewer.
The point is that you don't realise how USEFUL these sort of features are. Why shouldn't menus in an image viewer fade in and out and be semi-transparent? When you use it, it makes perfect sense.
I know there will be people who consider this sort of tech a waste of resources, and it can certainly be abused. However, if it's done properly this type of environment can add a LOT to your user experience.
I suggest you try DR17 to see exactly how impressive this sort of tech can be!
Re:I'll probably be modded down, but.... (Score:4, Interesting)
Re:I'll probably be modded down, but.... (Score:4, Interesting)
You see the key with this is that sometimes these features can be *really useful* and helpful, but they can also be very useless. The important factor is that the technology will be there to use or not use, its up to the developers whether they can find a decent use for it, and up to you whether you want to use it or not.
The most interesting fact is that using a little clever acceleration has made DR17 very, very fast. Thats what I'm trying to emphasise, DR17 is an example of where this technology can be both USEFUL *and* FAST!
Seriously, log into the CVS and give it a go!
Re:more extensions (Score:5, Interesting)
The X Consortium shut down in 1996, after declaring X11R6.3. At this point, it's not clear how an accepted X12 standard could be generated, even if people wanted to do so.
Linux vs. Apple and MS (Score:2, Interesting)
You want to sell users on the eye candy? HOW ABOUT A PICTURE???
Meanwhile, I know exactly what a MacOSx desktop looks like, even though I've never used a mac, and I've seen the eye-candy in Longhorn screenshots, and that OS isn't coming out for another year at the earliest.
Re:more extensions (Score:3, Interesting)
And lose that wonderful cross platform ability and userland protection? What color is the sky on your planet?
Moving the drivers into the kernel is crazy. It might simplify the X server code, but it will be a bitch to maintain for several operating systems. Not the whole world wants or does want to run Linux. What is it with the Linux contingent of FOSS-land and dumping everything into ring 0?
Where do you get the notion that the X server takes care of all the input devices? The kernel already provides access to them through</rant>
Re:more extensions (Score:5, Interesting)
Ok, slow down there buckaroo. Let's go through these points one at a time.
And lose that wonderful cross platform ability and userland protection?
X-Windows' cross platform abilities are inhibited by keeping driver code in the X-Server. Having OS specific code only leads to various build trees for each system, some incompatible. As for userland protection, no one is suggesting that X-Windows itself be moved into the kernel. Just the drivers which run in Ring 0 anyway.
Moving the drivers into the kernel is crazy. It might simplify the X server code, but it will be a bitch to maintain for several operating systems.
Nonsense. It's the Operating System's responsibilty to provide driver services. Shunning those services in favor of a hodgepodge of semi-userland drivers is silly. The X Server should float on top of the Operating System's graphical services, not cram a new driver model down its throat.
Not the whole world wants or does want to run Linux.
Preaching to the choir there. But that still doesn't mean that the X-Server shouldn't do its job correctly. It's not supposed to be a hardware manager, that's the OS's responsibility.
The kernel already provides access to them through
Not quite. Up until recently, the OS only provided raw access to the ports. X was responsible for managing these devices. As time went on (and BSD in particlar pushed back), X was modified to work with system mappings of devices. Unfortunately, X still demands direct control and can often screw up if it doesn't get it, or doesn't understand the device correctly.
Sure, the GFX side uses blitting directly to video ram, but that's what the others do as well. mmap(), memcpy and friends work fast enough from userland anyway.
The GFX side does not blit directly to RAM. X commands are queued up and shunted to the driver as appropriate. This may translate to blits, or it may translate to accelerated graphics commands. There's a major push at the moment to change all X operations over to OpenGL. If this were done, then the X-server would never need to see another blit again. It would simply pass a set of command primitives to the driver, and the video card would do all the work. Quite fast, quite easy, and quite correct.
And don't start about X using sockets to talk to clients, because they have nothing to do with networking
There is nothing wrong with X's networking. That's what it's designed to do. My point only addresses the matter of hardware control which X should not be in the business of. Look at a Sun machine, for example. The card is always in graphics mode, and those modes can be determined on the command line. All the X-Server does is take over the screen and begin drawing. It really doesn't care about the underlying hardware, as it should be.
I understand that you're upset about the old "X is slow" arguments and the like. Unfortunately, you're barking up the wrong tree here. My argument has nothing to do with performance and everything to do with architecture. Should the OS be given back control of the hardware, then it would again be possible to do things like run multiple X-Servers, run video games without X interfering, using graphics mode for the terminal, and other fun and interesting things. All because X would be a client of the OS, not a peer.
Or rewrite AA-XFT or just get back without XFT ! (Score:2, Interesting)
Accelerated drawing? (Score:3, Interesting)
What about MAS? (Score:1, Interesting)
Celebrity Desktop Deathmatch (Score:1, Interesting)
Winner to be announced on April 1 (That's when new releases of enlightenment are usually announced on
Re:RenderAccel (Score:2, Interesting)
creeepy stuff. (Score:1, Interesting)
It's not. X.org is cleaning up and improving the X window server by leaps and bounds. They packed more development and actual improvements in 1 year then XFree86 got done in six years.
On the other hand, KAA is fucking worthless. Waste of time, waste of effort.
Even though it's worlds better then XAA and WILL improve performance and WILL improve stability. XAA works, and it's fine.
You see the reason that it is worthless is because it's a driver model that's been obsolete for a couple years now.
We want to get it all working on a single software stack; opengl. That's it.
OpenGL isn't just for eye candy. It's for a unified driver structure for X.
You don't have hardware acceleration? No problem, you just use Mesa, it's just as nice as normal unaccelerated X. No eye candy, but what it does have is nice compatability.
Right now for Linux you need 2 or 3 drivers running _simultaniously_. Minimally 2.
That is 2 different drivers from 2 different sources running at the same time on the same card and outputing the information to the same display.
You need OpenGL drivers for apps that aren't 2d and you need 2d drivers for those that are. That's why X drivers suck, not because XAA sucks (although it does), but because the driver model for X is broken.
It's stone age, it's obsolete, no other operating system out there requires that you have do things like that. It is making the live of driver developers twice as hard as it should be.
Also the other problem is that X windows has control over the hardware.
X windows should not have control over the hardware. The kernel has control over the hardware. When X fucks up it can lock up your machine. Also X is a huge security hole. It is a major application that has to run as setuid bit.
It also makes having compatable X versions on wide veriaty of hardware difficult.
If you move the driver model to opengl then any machine with a OpenGL stack, even if it is just software, is perfectly compatable and it works.
The kernel drivers hardware libraries are the things that should work with your hardware not X.
This makes it possible to run X as a usermode proccess. This increases stability, portability, and security. Windows, FreeBSD, Linux, Solaris, embedded platforms, It doesn't matter.
If it has some sort of opengl stack and it's able to use the GNU tools to compile stuff, then it should work.
Then this opens up much more interesting possiblities for the future of X. Have any of you ever used sunray x terminals, for instance?
Think about 'screen' program, but for X windows... and network transparency...
You see that's what XGL is aiming at. Improving capabilities, providing the framework to take advantage of modern hardware (say anything newer then a 486). Improve stability. Improve security. Provide for future development directions.
KAA doesn't do any of these things. It's not even going to provide any new hardware-based acceleration.
The only card that KAA currently works on has the best OpenGL dri drivers out there. All the hardware that XAA runs perferctly fine on, will probably use KAA and be slightly better, if somebody wastes the time to completley rewrite already working drivers. And hardware that doesn't have opengl drivers or Xaa drivers isn't going to get KAA drivers either.
KAA is obsolete coming out of the gate. It would of been a great idea 5 years ago.
RGB subpixel anti-aliased font acceleration? (Score:3, Interesting)
Curious? Do a quick test:
x11perf -aa10text
x11perf -rgb10text
On my system, running X.org 6.8.1, regular AA text is about 8x faster than RGB-AA. RGB-AA produces no slow-down in Windows on machines I've checked, so it must be a driver or implementation issue.