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

When will we have...

[GreyWolf3000]

When will we have a non-monolithic distribution of X? I read it will be included in x.org 7.0.0, but in some places I've heard it'll come after 6.9.0 and other places I've heard it will come at the same time.

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

[TheRealJFM]

I already have a lot of these features via Enlightenment DR17. It's not finished yet but in terms of eyecandy and dynamic rendering its very impressive indeed.

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

[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:I'll probably be modded down, but....

[TheRealJFM]

My menus in DR17 appear instantly. That's because the developers thought that menu fading was useless ;)

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

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