Update: 03/24 18:50 by N: A group of KDE and GNOME developers have released an open statement on the matter. The statement doesn't say much that hasn't already been said, though it lays out some key issues in point form.

Comments

The new version supports a (non-backward compatible) new setup for multi-lingual keyboards, which doesn't work at all with the current kikbd and kcm module, both need to be changed to support the new API.
currently I don't mind that much because I use Mandrake which changed their keyboarddrake configuration utility to support the new scheme.

Politically:
* Actual admission that the XFree86 project is nowhere near as open as comparable projects - so far they are still maintaining their innocence
* Work to change this - effectively this means being less mean about giving out CVS write access given the current record of core team innefficiency, and actually engaging with the main users of their work.
* Stop believing that a few core developers are a better testing framework than their userbase. This is the bottleneck with driver updates.
* Sadly it seems unlikely that the core team will forgive Packard anytime soon. This is not brilliant, as he has been one of the most visibly productive members of the XFree team.

Technically:
* New build system - imake is awful. Autoconf/ automake are the obvious choice.
* Make disconnected trees easier - ie independently released drivers and extensions, which can be folded in later.
* Listen to what desktop projects, the main users of the software, want:
* Proper rendering model - ie RENDER like functionality that is implementable
on modern hardware, and is properly accelerated. Some suggestion that this
can be done via OpenGL - skeptics remain...
* Make expose events actually work properly - ie no crappy redraw updates
when windows are dragged around. This may be better solved by saving all
mapped window contents.
* Same with resize events - opaque resizing is excremental on X right now due
to syncronisation issues.
* Proper alpha channel model between toplevel windows- the shape extension
is sick, and transparent terminal/menu hacks are outdated.
* Good infrastructure for layering XFree on other window systems, ie
Win32,GDI,DirectFB, X itself etc. So reimplementation is not a chore.
Make it easy to get extensions like XVideo and glx working on top of other
window systems.
Also would ease transition to a theoretical X12, which would get rid of
core cruft and change the protocol to be more suited to modern networks.
Ie bigger packets, accept higher latency more gracefully. This all may be
acheivable within the X11 framework.

What sane people are NOT asking for:
* Getting rid of the wire protocol: this request implies a severe misunderstanding of modern graphics hardware and 2d performance issues.
* Moving network transparency to a screen scrape VNC model - this would be a massive step backwards.
* Changing the driver model for GGI or FBDEV - efficient acceleration would not be easy.

At one time I wanted to help with xfree, but I could not find any way to ease into it. Maybe I will try again if they clean up the pollitical situation.

Also using a modern rendering model that allows desktop opengl acelleration, and is not constantly forcing the windows to redraw would be a huge gain. Heck just saving all mapped window contents would be huge.

I also agree with the not list. I find it funny how all the x (as a protocal) bashers completely miss the point when demanding x reforms.

>* Proper rendering model - ie RENDER like functionality that is implementable
> on modern hardware, and is properly accelerated. Some suggestion that this
> can be done via OpenGL - skeptics remain...

What's wrong with RENDER? It's implementable on modern hardware, and it can be properly accelerated. What possible benefit would OpenGL have over RENDER?

RENDER is not a replacement for OpenGL in general, but it can replace the 2D portions of OpenGL for general windowing system use.

The original post implied that X needed a new rendering model besides RENDER. I was asking why RENDER was not good enough. When I asked what benefit OpenGL had over RENDER, I was asking "what benefit would using OpenGL as a new 2D rendering model for X have over simply continuing to use RENDER?" If the original post was only talking about implementing RENDER on top of OpenGL, then I misread it. But I think the post was talking about replacing RENDER with something else, possibly OpenGL.

Accelerated for those who have acceleration support. Some of us (especially laptop users) are so unlucky that we're using savage or other S3 video cards. Not everyone can afford to buy a laptop with Nvidia G4 :-(

There have been issues with accelerating RENDER.
Hopefully these issues can be addressed by eveolution
of the spec.

Currently *2 years* after RENDER was released, the mga driver has
absolutely minimal acceleration and thats it for free drivers.
XIG apparently has some acceleration too, after a fair amount of
hair pulling.

The problem was - the specifier, KeithP, didn't know as much about
the hardware as the driver authors and hardware vendors, and they
just didn't seem to care enough to have any real input into the process.
Hopefull all this can be solved....

The OpenGL issue: there has been suggestion that the RENDER extension
could be implemented over the top of OpenGL operations, with the X Server
calling the OpenGL implementation for all 2D operations. So the X Server would
become a user of the OpenGL implementation and most of XAA would go out the window. AFAIK, this would require the OpenGL driver to understand nested contexts - eg creating a context on a window which is then composited by the
root context onto anything else... this whole method begs the question - why not just use the OpenGL API to draw everything (and just have a legacy X11 proxy)?

The other idea was just to use the same facilities on cards as are used to implement OpenGL, and not reuse the drivers.

As for just using opengl, I think that is too simple. The x server should be handling fonts, understanding nested contexts, and so on. I see it as a good split. opengl for getting the hardware to do its work. And having an x server on top of it that does the windowing specific work.

1) Graphics cards don't support it yet. There is no point in defining another API if an existing, well support, and well established standard does the job.
2) RENDER (actually, Xr/Xc) is a 2D API. Not only does this restrict integration with more advanced OpenGL features (beyond the standard Postscript/PDF imaging model), it keeps the imaging model from taking advantage of the ever improving OpenGL API, and it makes life more difficult for driver implementors, who have to coordinate simultanious 2D and 3D rendering. To look at the big picture, both Xr/Xc and OpenGL are vector graphics APIs. There is no point in having two of them if you can have one and use a subset of it for 2D graphics.

Now, from what I've seen, OpenGL seems to be suitable enough for advanced 2D graphics. SVGL (http://www.lri.fr/~conversy/svgl/), for example, has already implemented an SVG viewer using OpenGL, and has seen incredible (up to 100x) performance improvements. EVAS already has a very good demo using OpenGL, and OpenGL rendering looks just as good as their software rendering. Xr/Xc tries to implement a pixel-exact rendering model, which is of dubious use. For things where pixel-level accuracy matters (fonts), one can always use textured 2D triangle bitmaps, which is precisely what Quartz Extreme in OS X does.

More Info: The Amaya people also seem to be working with SVG and OpenGL:http://www.w3.org/Amaya/User/gldev.html
Scroll down to the bottom of the page for some notes they made about using OpenGL to implement SVG.

Another political / technical challenge is how to get the X consortium to accept changes. There are some issues with X itself that need fixing, and some feel there hasn't been effective representation to bring necessary changes.

This whole thing will probably improve the situation for everyone. Every project goes through defections and controversy. Usually the issues are fixed as much as possible, and hopefully with time everyone simmers down. Even a fork may be necessary to permit an experimental approach on one hand, and a stable tree on the other.

before i start:
1. I don't mind using X.
2. I wouldn't mind -- corr. -- would love to see an alternative to X
(and make used of it with KDE)
3. I am running the latest X server and liking it...
...i thank the X team for so much end-user-impotant-changes!

I just compiled it, it is nice and all, but slow (I.e. unaccelerated on my machine) Setting the default window opacity to 255 (100%) results in an ugly magenta background where transparency once was. Setting to 254 fixes the problem. Also, make sure to turn off the fade effect on menu transitions. Animate works, but it creeps out at a slow,steady rate instead of just popping out.. There are quite a few nice features to this (besides the ability to have true transparency with windows). For instance, all cursors get a soft drop shadow (I.e. MS windows cursor shadow). I haven't tested it with my cursor sets though.

Hmm, it must've not been in the official release because I reverted to the pre-compiled binaries and there is no shadow (with the exception for the CursorShadow option which I have used since the beginning of 4.2). oh well :)

Setting it up is a pain though. First, It is really just a patch to XFree86, so you have to download the huge sources (100MB+ or so) and compile everything. Second, you have to somehow get it to co-exist with your existing XFree86 installation (not easy, but not XDirectFB's fault).

I used it around summer of 2002, and it worked pretty well. Unfortunately, it didn't support many of the X extensions, so some apps refused to run (notably VMware and anything 3D). On the positive side, setup is a breeze. It uses the keyboard/mouse/video drivers of the kernel, so things just work. The transparency tricks are a bit useless, but they prove a point. XDirectFB also claims to be able to run normal DirectFB software (like that GIMP port), managed with your X11 window manager. I never tried this, I was just happy to be using a nicer X server for once.

I went back to normal XFree86 a few months later. IMO, XDirectFB is the future of the Linux desktop, but it is not ready yet.

I think linus desktopping will stay with X for a looooong time, cauz:
- desktop pc's are getting faster and faster
- x works and does a lot
- lot's of stuff dep.'s on/uses x...
- when the FB stuff matures we want networkt transperancy in it ;)

I think opensource movement must be happy to have a good standard!
But the freedom of choosing something less bloaded will only enrich...

Not sure if this is OT or not but everytime the discussion comes up on ./ about throwing out X, someone suggests that X itself is not slow, but that the modern toolkits (gtk and qt) are not written to take advantage of X (ie they redraw incorrectly etc).

I actually have no clue about this but was wondering if anyone here could explain it. Obviously KDE does a lot more that twm, but is this eye candy that is slowing down X or toolkit problems?

Does QT have inherent X problems (I wouldn't think this to be the case)?

I don't know anything about redrawing "incorrectly", but I'll try to take a stab at it...

The way Qt draws themes involves drawing primitives with X11 (or GDI under win32). For a complex control such as a button with a bevel, gradient background, pixmap icon, and AA label, a lot of primitives get called to draw the button. This happens each time the button is redrawn. To make things go faster, the obvious solution is to cache a pixmap of the finished widget the first time and bitblt on any redraws. But who does this? X11, Qt or the theme? Either one of the three are viable options. The best choice though would be X11, as this sort of stuff belongs on the X server. There is some areas where Qt should cache or double buffer, and it does. But Qt is merely a toolkit, not the base GUI system. It shouldn't have to worry about whether the server is local or remote, whether some window is going to intercept any drawing events, or whether to use video or local memory to cache in.

Don't know anything about what Qt/GTK do right or wrong,
but here's another possible culprit: the scheduler in
the kernel (i.e. Linux in most cases):
X11 is a user-space process. So, whenever a GUI application
reacts to a user event (eg. a mouse-click), the CPU has to
switch from the X11 process to the application process and
back. Many think that the time it takes to do these context
switches is the problem. However (particularly since Linux
is pretty fast at context-switching) I can't imagine that
this takes more than a few milliseconds (probably even less
than one) - so that would hardly be noticeable. But if the
kernel doesn't switch directly from X11 to the GUI
application (or back) but instead gives a timeslice to
yet another process in between, the reaction to the user
event will lag.
The brute force way of dealing with X11 slowness proposed
by many is to put the graphics driver in the kernel. But
that wouldn't even deal with the problem above: the gfx
driver would probably be implemented as a kernel thread,
and if that isn't scheduled correctly, you still get a
slow GUI. The only advantage would be that you could
give special treatment to that thread in the kernel since
the kernel knows that this is the graphics driver.
But that special treatment could also be done for a user-
space process, so in the end putting the gfx driver in the
kernel doesn't buy you much - but gives a lot of headaches
instead: Gfx drivers are pretty complex and hence often
instable - at least when compared with the stability of
Linux.
Anyway, I've heard that the kernel developers are on it
for 2.6. As usual with the Linux developers, they don't
want to hack up a special treatment for X, but go for a
generic solution, because apparently there are other
situations where the same scheduling problem arises.

If the problem was coming from the scheduler giving too much cpu time to other processes instead of X when switching context, then it would be relatively easy to correct it by giving an higher priority to X. However, this doesn't increase X performance on a mostly idle system. As X is also slow on these systems, the problem is probably elsewhere in the X architecture.

You are saying that X11 is slow all the time. I wonder how you come to this impression. Maybe you have a slow driver? With both the ATI r128 and the proprietary nvidia drivers I was never ever able to see a redraw or something else that would make X11 appear slow.

I'm using the ati driver. I know that 3D support on the mach64 is experimental on Linux, but won't use it as a point of comparison. However, I think 2D graphics performance can be compared with Windows, and window moving/resizing is really faster on Win2K, even if my CPU is idle. The difference may not be visible on new hardware, but isn't Linux useful on older computers?

I can't comment on Qt, but the right way to do X11 calls is to minimize interactions between the client and the server, especially during a redraw. You should minimize queries on the client-side, and especially should not put a query between your drawing commands.

The general problem with xlib is that it is not transparent which function will cause a interaction with the server, and under which circumstances. xlib will cache information to a certain extend, but it is often hard for the application/toolkit developer to find out when it caches.

A few people have worked on a more direct, non-caching API for the X11 protocol called XCB (http://xcb.wiki.cs.pdx.edu/cgi-bin/twiki/view/XCB/XcbOverview) which would make this more transparent for the toolkit developer. I don't know it's current state, last time I checked it lacked support for most extensions, and AFAIK not a single toolkit has been ported to it.

Its easy enough.
1a)go to www.kdelook.org, www.themedepot.org or some other theme/resource site and get a new icon set.
1b)Use one of the default icon themes that are shipped with 4.3.0(or 4.2.99). They are whiteglass, redglass, handheld, and core(the old B&W default).
1c)Make your own :)

If installing for a single user(or a particular user):
2)make the directory "~/.icons"
3)copy the "cursors" directory and "index.theme" from the archive to ~/.icons
4)restart X

If installing system-wide:
2)extract the archive contents to its own directory in /usr/X11R6/lib/X11/icons
(E.g. you would have a .../X11/icons/reddot directory with its own cursors directory and index.theme
3)edit the index.theme in the default directory to say:
[Icon Theme]
Inherits=theme
obviously replacing theme with the themes name

Alternatively, if you just want to test a set out you can set the variable "XCURSOR_THEME" to a cursors name and "XCURSOR_SIZE" to set the size of the cursor to any size (yes, you can have a 128x128 cursor if you wanted to)

It seems like the people at the XFree86 project had ( or have? ) their eyes closed for a long time.
When you open your eyes and look around you'll see two big players on the desktopmarket. Apple has done a great job with their latest OpenGL accelerated userinterface. Really slick, and one of the major reasons OSX became intresting for the desktop. Microsoft is planning Direct3D acceleration for their graphical shell, and will surely not take long to be implemented. However XP has nice graphics, they too realize that it is time to go further. Especially now a 3D accelerated card is all but rare in today's common homecomputer or workstation.
In the mean while, the GNU/Linux OS becomes more and more popular. While applications shipped with current distributions get better and more accessible to common homeusers, the graphical environment is still behind the commercial implementations. Things like antialiased fonts and the new features of XFree 4.3 are surely a step forwards, but it can be so much more.
I can not imagine there aren't people who share my desire of a fully OpenGL ( <- most obvious choice imho) accelerated desktop showing of nice effects that make OSX users cry, unmatched performance, and a better chance of graphiccards companies writing drivers for it.
I realize that not everyone has a state-of-the-art graphicscard in their system, but that problem could be solved by just letting the OpenGL renderer run in software mode. Backwardscompatibility should -however i am not familiar with the current XFree codebase - not be hard to achieve, writing simple wrappers or emulation layers.

So the question may be: "Is it wise to stop innovation in fear of releasing the past?"

I think it's time to look closer at people who have already achieved what the goal should be for the current graphical environment(s) on the GNU/Linux platform.