Xorg and Desktop Eyecandy

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."

Comments

Re:I'll probably be modded down, but....

[ratta]

While i love enlightement, evas just provides i a layer on the top of X (or some thing else). A new x driver architecture is requite to let evas, qt, gtk (and your other favourite toolkits) to really take advantage of you graphic hardware with accelerated alpha blending and window backing store. This is not to compete with evas, just to allow it to do better things.

Re:more extensions

[Otter]

well the core of X hasn't changed substantially in .. over a decade.

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.

Re:more extensions

[AKAImBatman]

/Me offers CoolVibe a glass of ice water

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 /dev anyway.

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. :-)