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.

Linux vs. Apple and MS

[Anonymous Coward]

You know why Linux is destined to fall to a distant third place against Apple and MS? Crappy marketing. I clicked through every link in the post, and searched around for about 10 minutes, and couldn't find a single screenshot of the so-called "eye candy".

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

[CoolVibe]

Moving these drivers to the OS level would improve reliability and configurability all around.

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 /dev anyway. 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. And don't start about X using sockets to talk to clients, because they have nothing to do with networking (although networking does work, which comes for free). X uses a domain sockets/named pipes (which don't need a network stack) locally, and it's hella fast. Faster than other kludges that other unnamed operating systems use. If you ever see X redraw or rubber-band, don't blame X, blame the toolkit used. X can keep up fine. :)

</rant>

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

Or rewrite AA-XFT or just get back without XFT !

[dascritch]

This is going worst as Deer Park won't accept GTK without XFT. It's too slow, too ugly, too illisible and ... http://forums.mozillazine.org/viewtopic.php?p=1510 011 ... people in forums have just bogus responses like "upgrade upgrade upgrade". They don't want to understand that anti-aliased fonts are completely bogus in normal sizes. Raster fonts are better at "small" sizes, they matches exactly what it should look at, how the artist think it. When I look at vector fonts with or without AA, I just believe that my mobile phone has BETTER LISIBILITY that my pc... it's... irrationnal ! If Qt/GTK could have an option "prefer raster that vector", I will be soooooooooo happy. This is also impacting speed and comfort.

Accelerated drawing?

[Decimal Dave]

Will this new architecture be extensible enough that the primitive drawing routines can be implemented as fragment programs (like Quartz 2D Extreme)? There was a huge speedup for those that enabled it on OS X and I'm sure X11 could reap the same benefits. It makes a lot of sense to offload drawing and compositing to the GPU, but I couldn't find any reference to it in the article.

Re:RenderAccel

[Astatine]

I'd note that in my experience, the Nvidia driver's RenderAccel option is OK on generations NV2x and later (GeForce3, GeForce4 Ti, GeForce FX, Quadro FX, etc) but dodgy and prone to causing crashes on NV1x (GeForce4 MX, some Quadro NVS such as the ones in all the recent cheapo Dell workstations my company has bought us, grr). In fact, I believe it's documented that running KDE 3.4 with an NV1x GPU with RenderAccel enabled will cause an instant X server crash. Check your GPUs...

RGB subpixel anti-aliased font acceleration?

[Ogerman]

I don't know about anyone else, but my biggest gripe with X performance these days is the rendering speed of RGB subpixel anti-aliasing. (at least on Radeon cards, which is all I have..) It's not unusably slow, but it's highly noticable and makes everything feel sluggish.. especially scrolling.

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.