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

Page layout doesn't bode well for their server

[farker haiku]

I don't want to judge, but based on the page layout, this server is about to get fried. Article in question:

As some of you know I've been working on bringing in KAA to X.Org to replace XAA.

XAA is nowhere near being enough for the modern desktop usage. It's plagued by being rather complex and incapable of properly accelerating XRender.
The two main goals of our new acceleration architecture were:
1) properly accelerating XRender,
2) being as simple as possible.
The first one is aimed at making sure that people can run composite manager on very low end hardware for as long as Xgl isn't ready to go mainstream. The second was set to make the transition as simple as possible for driver developers.
That's exactly what the new architecture achieves. For the purpose of this email lets call the new acceleration architecture Exa. It's heavily based on KAA. It incorporated the memory manager from KDrive which does wonders for the common desktop usage.

So lets get to the question everyone wants to ask and that is: how do I get a usable xcompmgr with the new architecture?

1) include "exa.h" in your driver and load exa,
2) use the code from XAA primitives for solid-fills and screentoscreen copies to implement Exa's Solid and Copy hooks. So no real changes at this point.
3) create an ExaDriverRec structure and fill in the accel hooks.
4) call exaCardInit(exaDriver, memory_base, off_screen_base, memory_size, offscreen_byte_align, offscreen_pitch, flags, max_x, max_y); to let the system know what are the capabilities of your card. This is really a convenience macro and you may fill in all those individually if you prefer that.
5) exaDriverInit(pScreen, exaDriver); once you connected yours hooks and setup your card.
6) replace xf86AllocateOffscreenArea with calls to ExaOffscreenAlloc

This should be enough to get a more less usable xcompmgr on your hardware.

Now if your hardware is below 1.5ghz you want to implement two more hooks:
- DownloadFromScreen,
- UploadToScreen,
this should be enough to get you happy with the basic composite manager on any hardware.

Now if the transparent windows aren't enough and you want things to be way more fancy, implement the last of Exa hooks meaning the Composite hooks. I'm planning to write a paper sometime early next week on how to implement composite acceleration and DownloadFromScreen/UploadToScreen
hooks in a simplest/best manner on typical hardware. So don't worry if you're not certain about how to do it quite yet.

All in all the code is available at:
http://ktown.kde.org/~zrusin/dev/exa-snapshot.tar. bz2

I'll be here to respond to any questions. If there's anything you think is silly, I'll be more than happy to change it.

I refuse to add acceleration hooks for low level primitives (e.g. lines). At this day and age it really just doesn't make any sense.

I will also provide a sample ATI R200 driver implementation (didn't feel like cleaning it up today :) ) along a document on how to implement composite acceleration sometime next week. All the cards which don't currently have a maintainer but are using XAA will be ported by me, as soon as I get the respective hardware in my hands.

I want to make sure the following things are very clear:
1) Exa can coexist with XAA. You can keep code for both in your driver.
2) Exa doesn't depend on any changes to the Xserver. Once we'll feel it served its purpose we can simply remove the exa dir and the relevant driver code and we'll be sure that no cruft has been left in the server.
3) As everyone can see adding Exa support to a driver which already has XAA support is trivial.
4) Following the 7 steps I outlined above will speed up the common desktop usage by quite a bit. Note that you don't have to be a driver developer to switch any of those drivers. Note that this also means that we can easily give the u

Informative comments are useless...

[ratta]

if they are going to be modded -1,flamebait by uninformed moderators. In my previous post i wrote that Exa is a temporary solution before Xgl (as it is http://lists.freedesktop.org/pipermail/xorg/2005-J une/008356.html), please think before modding.

Sounds great. BUT!

[CAIMLAS]

When are they going to make it modular like they said they would, so that those of us that don't want the fancy accelerations can still have a relatively 'modern' desktop using modern software without the tremendous bloat? I want to use my memory for applications, not to draw graphics.

It's getting to the point where 512Mb isn't even enough for a GNOME desktop. That's partially GNOME's fault, but for chrisake! Xorg is huge.

They said they were going to prune the tree; why haven't they?

Re:Full Replacment

[BlueLightning]

Mostly, X is not the problem. It's the drivers that cause most of the crashes that bring down X.

Rewriting X from scratch is not a good solution. Aside from the massive effort that would be required to duplicate X's basic functionality, there will be even more work to maintain compatibility. If you don't maintain full backwards-compatibility with X then you'll also have to rewrite all the current environments, applications and libraries that run on it. A lot of developers won't be interested in doing this and so not everyone will be able to / want to use the new system. You'll have an even worse problem getting companies like nVidia and ATI to write drivers for it.

The truth is that X is a good solid base upon which a very decent desktop can be built. What we really need is the drivers to be more stable (and only hardware manufacturers can help here), but also in general get everyone working more closely together. I think we're already moving towards that.