Athene 3.2 is now available for download. In conjunction with this release a port of SDL is available, along with a number of games at rocklytefiles.com. ZTerm has also been upgraded to provide full terminal emulation and is now installed by default in the 3.2 release. Rocklyte Systems also announced that the latest release of the freely distributed Athene for X11 overcomes one of the X Window System’s most pressing speed constraints. Testing of the new release demonstrates graphics throughput approximately twice as fast as previous releases of Athene, by bypassing conventional X11 programming techniques and using the ‘shared imaging’ hack to copy graphics to the X video display.
Athene 3.2 Available; Overcomes X11 Speed Constraints
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
IIRC that’s what MacOS X does. However, it also prevents you fully using hardware acceleration.
I’d be interested to know *exactly* what they are doing here. “Shared memory” is very vague, X already uses SHM segments for pixmaps. Are they talking about DGA?
Oh, rereading the announcement, it seems that all they’re doing here is using the XSHM extension. That’s old news, every toolkit has used that for years. I guess it makes more difference to Athene because they render all the stuff internally, rather than compositing lots of small pixmaps serverside so raw throughput actually matters to them.
Still, it’s kind of misleading to say “traditional window managers cannot make that claim because they only direct traffic” – as I said, every toolkit these days uses XSHM.
From the release page:
>> we still have a research objective to release a complete X11 replacement for the free software world
Sounds interesting
There are a couple of points to consider here:
1) They don’t mention what drivers they are using. Some drivers (particularly NVIDIAs) are much more optimized than others. They’re getting about 190MB/sec using XShmPutImage, which might be right, depending on their hardware. I get about 300MB/sec on my GeForce4Go, using the NVIDIA drivers. So unless they’re using a different set of drivers, the comparison is pretty decent. Interestingly it shows what the X11 guys have been saying for awhile now — the problem isn’t in X! There is only a 14% difference (on their benchmarks) between X11 and the GDI. The bottleneck is definately somewhere else.
2) They’re using X11 very differently from how most Linux GUIs use it. With X11, if you have a pixmap that doesn’t change, you allocate it server side, to take advantage of hardware acceleration. Copying a server-side pixmap to a window happens at about 2.2 GB/sec on my machine. That’s *very* fast, even compared to using DirectX. Note that most of the pixmaps that you see on the screen (buttons, gradients, widgets, images, glyphs, etc) don’t change, and can thus be allocated server-side. Heck, even 2D games tend to allocate pixmaps server-side. In comparison, Athene appears to render most of its stuff client-side, and blit the results to the server. This is a non-optimal way to use X11. Heck, its even non-optimal with the GDI!
3) I really don’t think their rendering model is a good idea. Modern graphics cards are abstract. They don’t like you messing around with their graphics memory. This has been the case since the original Radeon (read up on some of the stuff that was written about the BeOS Radeon GL driver). Composing things server side is a much better way to get good performance than treating the server as a dumb framebuffer and doing everything client-side. It makes some things more complicated (custom canvases, text layout, etc) but if you want to take advantage of advanced acceleration in modern graphics hardware, server-side is the way to go.
Okay, so I installed Athene 3.2. Boot up. Its pretty. Love the icons (Noia by Carlitus). Start up some programs and resize some windows. Resizes real smooth. No flicker, no toolbar lag. Okay, now what? None of the themes are very visually complex (nothing as complicated as ThinKeramik, which I’m running in KDE) so I’d expect them to be fast. None of the apps are very visually complex, so again, I’d expect them to be fast. I reboot into KDE. Startup Kate and load a large text document. Resize the window. Text reflows without the slightest hint of flicker or toolbar lag. Startup KFind. Resizes with zero flicker from any of the widgets. Start up Qt Designer, which is probably more visually complex than any existing Athene app. Resizes with absolutely zero flicker.
Look, I’m a twitchy user. I used BeOS as my only desktop for more than a year! Still, a few cases of pathological behavior aside (there is some cleaning up in ThinKeramik that I want to get to this weekend) I can’t imagine using another desktop that has 99% fewer features, just because its 20% (that’s being generous) faster than KDE.
IMHO, Rocklyte is going about this Athene thing all wrong. What’s interesting about their technology is not that its marginally faster than the existing GUIs on X. The interesting aspect of their technology is the whole DML thing, which I think has a real chance of making GUI programming suck a lot less. They should be concentrating on that, not trying to ecke out a few percentage points of performance here or there.
I’m curious… did they develop their own xlib replacement that implements core graphics calls which draw to a shared memory buffer, rather than passing them on to the X server? This is the sort of display model I’ve been saying X should move to for years, at least for local clients. The context switching pentalties of CoreGraphics operations are just too severe, especially in a unithreaded display server like XFree86. Moving to client side rendering allows multiple concurrent graphics operations as there are multiple processes performing the rendering.
The next step would be for Athene to release an X server without a core graphics implementation. This would drastically improve server startup time, decrease memory usage, and could have additional performance benenfits once all the untaken branches are removed.
I’m curious… did they develop their own xlib replacement that implements core graphics calls which draw to a shared memory buffer, rather than passing them on to the X server?
>>>>>>>>>
They needn’t do anything this drastic. They could simply use XSHM to draw directly into shared pixmaps.
This is the sort of display model I’ve been saying X should move to for years, at least for local clients. The context switching pentalties of CoreGraphics operations are just too severe, especially in a unithreaded display server like XFree86
>>>>>>>>>
There is no indication that the context-switching time is at issue here. xlib is heavily buffered. Thus, unless your application has some pathological flushing behavior, there shouldn’t be too many context switches. The real problem is that xlib is too high-level of an API. It does buffering that would be better handled in the toolkit, and makes a lot of function calls synchronous, which causes a full round-trip and a context-switch. A lower-level API, like XCL, which offers more direct access to the protocol, would be better for advanced toolkits like Qt and GTK+.
Moving to client side rendering allows multiple concurrent graphics operations as there are multiple processes performing the rendering.
>>>>>>>>>
That’s true, but:
a) That only helps on dual-processor machines, and hurts on uni-processor machines;
b) It makes it difficult to effectively utilize modern graphics hardware. Modern graphics hardware is pretty single-threaded. They do not like multiple applications accessing them simultaniously. If you want to optimize the total throughput, then a single-threaded server in full control of the hardware is the way to do it.
>” I reboot into KDE. Startup Kate and load a large text document. Resize the window. Text reflows without the slightest hint of flicker or toolbar lag. Startup KFind. Resizes with zero flicker from any of the widgets. Start up Qt Designer, which is probably more visually complex than any existing Athene app. Resizes with absolutely zero flicker.”
I’m sorry but just I don’t believe that, even on windows I can see flickering when I resize IE or mozilla, let alone on my linux box. I have a geforce ti4200 and i’m using the latest nvidia drivers on both.
is the downloadable version of Athene 3.2 XFree dependent?
Athene appears to render most of its stuff client-side, and blit the results to the server. This is a non-optimal way to use X11. Heck, its even non-optimal with the GDI!
No, you are completely wrong about this. If this is so sub-optimal, how come KDE and GNOME aren’t sporting the graphical effects that Athene has? Where is their fast fading / translucency / selective transparency / blending etc? If they are using the optimal method as you indicate, how is Athene capable of producing these effects with ease and reliable performance where they cannot?
The fact is you cannot pull off these effects under the standard X11 window management model and get good performance out of it. I have tried and it just doesn’t work. The X11 window model simply was never designed to do such things – it has to be hacked into the system and the performance is awful.
Rayiner, you have to consider more carefully what you are saying. These knee-jerk reactions are totally untruthful and do not give a complete picture of what is going on here. Yes there can be disadvantages, but the benefits outweigh them and I have been deep enough in graphics research for years to know Athene has got it right. There is no balance to your arguments whatsoever and your outright negativity shows that you are little more than trolling here.
Notice I used KFind, Qt Designer, and Kate as examples, not IE or Mozilla! I use these simpler applications because they are most comparable to the apps that come with Athene. A complicated app like Konqueror that uses a custom canvas isn’t a real good benchmark of a windowing system — but rather of the drawing logic of the application. Rendering HTML (+CSS and all those modern web-features) is complex enough that *any* web-browser needs sophisticated algorithms to minimize the appearance of redraw.
PS> Konqueror rubber bands on my machine, but mostly only on complex pages. Its not yet as good as IE, but its getting there. Mozilla rubber-bands like hell on my machine.
They needn’t do anything this drastic. They could simply use XSHM to draw directly into shared pixmaps.
Draw *what* though? Prerendered windows? That was my guess, but that would require offloading X’s core graphics into xlib itself.
Are they using their own homebrew X implementation?
Try for example resizing a knote (no window manager) smooth as it can be. When using the window manager there is a lag between the resize of the window manager’s border and the application. I believe an extension is being worked on to allow synchronized updates between the window manager and the application.
Again the raw speed of X is *not* the problem (not clever is a better term). Still not convinced: Alan Cox made some comments about it on the Xouvert mailing list. ( http://mail.gnu.org/archive/html/xouvert-general/ ).
No, you are completely wrong about this. If this is so sub-optimal, how come KDE and GNOME aren’t sporting the graphical effects that Athene has? Where is their fast fading / translucency / selective transparency / blending etc? If they are using the optimal method as you indicate, how is Athene capable of producing these effects with ease and reliable performance where they cannot?
>>>>>>>>>>
Exactly where am I wrong? Point to a specific statement instead of waving your arms about. Are you arguing that client-side rendering on X11 is faster than server-side rendering? Or that client-side rendering is faster than server-side rendering on GDI? Most programmers of either system would disagree with you on that one. Also, the benchmarks prove you wrong. If I want to compose a scene with some bitmaps, I can either do it client side, and send the result to the server at 300MB/sec, or I can do it server side, and blit the bitmaps at 2GB/sec.
Now, where your misunderstanding comes in is that you assume that I’m talking about a system with fading/transparency/etc. I’m not. I’m talking about what style of X programming is efficient, and what style is inefficient. Now, because X11 does not support server-side transparency, there is no efficient way to render with fading/transparency/etc in X (at least, not until Render acceleration becomes more prevalent). The fact that its efficient *enough* for Athene just means the overall system is fast enough that the inefficiency doesn’t matter. It still does not change the fact that this is not how X was designed to be programmed.
My guess is that they’re doing what something like what OS X does — draw via a software graphics library into server-managed pixmaps, and have X11 blit these pixmaps. Their complaint about regular server-side pixmaps not allowing direct access via the CPU seems to indicate that they’re doing some sort of software rendering, and they’d have to, if they wanted fancy features like anti-aliased primitives, which core X doesn’t support yet.
The link Vincent posted is a good one. In particular, Alan Cox replies to a question asking whether an X11 game needs to continually pull bitmaps over the network:
“Not unless the program was written badly. X provides the notion of
images you can manipulate either server or client side. So *good* software pushes the images it needs to the server once. A redraw then triggers nothing more than a new draw request citing the image already held remotely. Games like xmris do this to great effect and are playable over the network as a result.” [Emphasis mine]
You should probably mention what version of KDE you are using on your laptop, as you did in another news item.
You said KDE3.2 from CVS right? Also you see hardly any redraws any more.
Also what version is Sagres using. In this case is it a KDE or X11 issue.
Also Rayiner I think you said your laptop has a 2.4 Pentium 4M.
From my experience I have noticed KDE is CPU frequency dependant, just as much as RAM. (Just an observation using my schools P4 1.8Ghz Vs my K6-2 450Mhz) Also the KDE caching is more effective on newer processors.
Eh, sorry ’bout that. I’m using 3.2 CVS on a P4-M. Yes, I’ve found that KDE benifets from CPU moreso than either GNOME or WindowsXP. For example, KDE and XP are almost neck-and-neck on my machine, but XP is way faster on my mom’s Duron 700.
My guess is that they’re doing what something like what OS X does — draw via a software graphics library into server-managed pixmaps, and have X11 blit these pixmaps.
So what was your problem with my original statement? Do you not think this “software graphics library” is implemented with xlib’s API? If not xlib, what is the API for this library?
is the downloadable version of Athene 3.2 XFree dependent?
The free version uses X11. The commercial download version uses Scitech’s SNAP.
If not xlib, what is the API for this library?
The Pandora Engine. This does the bulk of the rendering and then the images are off-loaded straight to the graphics host (or done native in the commercial version). Pandora can make hardware calls too if you need to draw directly to video, but that’s intended more for full-screen games rather than desktop apps where multiple tasks are active.
To try and answer your questions, Pandora and Athene use X11 simply as a display output device rather than the conventional window management usage. We haven’t had to add any special hacks along the way to implementing this.
Now that I think of it, its really just a matter of semantics. The word “replacement” kinda threw off your meaning. A software renderer wouldn’t be a replacement for xlib, because the majority of xlib is devoted to handling non-drawing related protocol stuff. Instead, the application would simply refrain from using xlib’s drawing commands, instead using its software library to render into an SHM buffer.
I’d like to have more online information regarding Athenyx (not Athene) beyond an austere FAQ.
I already knew about Athene, but Athenyx is new to me. It would be a wonderful idea with an improved capable GUI in the Oeone.com or Haystack.lcs.mit.edu vein (a browser-centered GUI). A true ***DESKTOP*** orientated Unix (“outside Apple”) with the latest multimedia requirements. Is this -The- GUN??? Could be. Hey, I can dream, can’t I? ;D
Brings to mind Bill Hayden’s sincere words:
Quote
Another reason for this project [ Cosmoe.com ]is my loathing of X11. I tried to like it — I really did. However, after trying to make sense of this decades-old monstrosity, I came to the conclusion that it should taken out behind the barn and shot. Cosmoe is my gun.
End Quote
Well, I’m running it right now..
It (window dragging, etc) really isn’t all that fast with GeForce3 Ti 200/NV-binary driver but the effects are very nice (and faster than the usual XF86 fluff)
*bit later..
Hm, wait.. the window dragging seems to be a lot smoother now that I’m running Mozilla on top of everything 😕
(normally, Mozilla makes my system slower instead of faster
)
What’re you talking about? What’re you running now? And how can window dragging *not* be smooth? Every GUI I’ve used in a long time (since KDE 2.x!) has had almost perfectly smooth window dragging. They darn-well-better, since window dragging is just a blit-operation. Do you mean window resizing?
In regards to your comments, it sounds as if Pandora is completely discontiguous from X11. If so, why are people reporting performance increases from X11 applications? Are these people simply confused? Shouldn’t this only affect applications specifically developed to use Pandora?
In regards to your comments, it sounds as if Pandora is completely discontiguous from X11. If so, why are people reporting performance increases from X11 applications? Are these people simply confused?
Right, running Athene inside an existing window manager like KDE does not affect the X11 applications that might be running at the time. The separation between the Athene desktop and everything else is quite distinct.
Shouldn’t this only affect applications specifically developed to use Pandora?
Correct.
Anyone noticed the setup of the computer in which the test was made ? Rocklyte ? Please .. ?
Intel Pentium III 450mhz, 320MB RAM, NVidia GeForce 2 MX Series. Test OS’s: Windows 2000 / Red Hat 9 / Athenyx 2003
As this was a pure throughput test for the windowing systems, the quality of the gfx drivers also never entered the equation (a straight CPU copy from software to video RAM does not require any driver intervention). The differences between each system comes down to the quality of the window layering code, latency, design issues etc.
The benchmark was run 10 times for each system and the lowest (best) results were used in each case so that they were all fairly represented.
>> What’re you talking about?
Athene 3.2
>> What’re you running now?
Athene 3.2 (on a RH 9.0.93 (Severn) system)
>> And how can window dragging *not* be smooth?
It is kind of smooth, but it’s also looks/feels like the system is having a hard time with it.
It feels like it’s a bit less responsive compared with normal XFree86(/KDE).
On the other hand, dragging that Amiga-style window up and below was the fastest I’ve ever seen on XFree86.
Dragging smaller things like (translucent) icons around is very smooth (a very big improvement over the usual KDE desktop ‘experience’)
>> Every GUI I’ve used in a long time (since KDE 2.x!) has had almost perfectly smooth window dragging.
Yes, if you’ve only got one window on the desktop it’s indeed fast (smooth is something different).
But once I start adding more windows, things become slower when moving a window around (not really worse, but it’s just that tiny bit that makes it a source of irritation).
It’s just not Windows-quality-fast/smooth..
(I’m talking about raw XFree86 here, not Athene/Pandora)
>> They darn-well-better, since window dragging is just a blit-operation.
Yes, and that’s what makes Mozilla run on top of the whole desktop (including apps).
>> Do you mean window resizing?
No, altough that’s suffering from the same issue; it feels like it’s less responsive.
Hi Rich, Athene will perform to its best if you kill X11, go back to the console and type in ‘athene -xserver’. This way you’ll get a full screen desktop without outside interference from window managers, apps and so forth.
Also, watch your system resources. If you run a lot of apps this can have an impact on overall performance when programs start chewing up memory and CPU time.
On another related subject; I’m looking for a C++ programmer who understands X well enough to modernize an X application we have.
email to [email protected]
Use the word Interested in the subject line, please.
Hi Paul,
While Athene does seem a bit faster using -xserver, I don’t see much point in using Athene right now. There’s very little functionality built into the desktop, no way that I can easily tell to disable things like the annoying menu fading, and this supposed ‘bypasses X11 performance problems’ doesn’t appear to be anything great. I can’t really tell any difference between RedHat 9’s Gnome 2.x and Athene when it comes to window moving or resizing. Even not comparing them, Athene’s Window resizing and movement is still nowhere near as smooth as what Apple has in Mac OS X. I don’t suppose you can compare Apple’s … Of course Athene may not even work on the Mac yet…
I can’t really tell any difference between RedHat 9’s Gnome 2.x and Athene when it comes to window moving or resizing. Even not comparing them, Athene’s Window resizing and movement is still nowhere near as smooth as what Apple has in Mac OS X
Ahem – that’s why we have the commercial version, which has 29% more throughput than X11, as shown in the benchmark. It’s very smooth and would compare just fine to a similarly specced Mac
.
When it comes down to it the X11 version is now as fast as it’s going to get, so if we want to provide anything faster than that for free, we have to either dump X11 or make extensive modifications to it. As indicated, we are working towards doing one or the other