Python slithers into Wesnoth [LWN.net]

Python slithers into Wesnoth

Posted Jan 15, 2009 22:57 UTC (Thu) by jengelh (subscriber, #33263)
Parent article: Python slithers into Wesnoth

Computers getting faster is an illusion. Games like Wesnoth provide a refuge for older boxes that, for example manage to run the Quake3 engine, get shaky at Unreal2003 and just do not make a usable game out of America's Army, to give a perspective what we're talking 'bout. And now he is gonna take even that away by making it slower - and the P programming functions with their current VMs are ten or more times slower than pure-compiled stuff and the SunJava JIT engine.
And then this: the X Window System sucks for 2D graphics - I have seen a GL context being more effective (more F/s) in low-end graphic game (-> ZDoom) than drawing to Xshm. (Most of these apps do not support output to Xvideo; and who knows how much extra cycles would be needed just to make SDL convert RGB to Xvideo acceptable formats like YUV.)
Even if it were not for X, other programs running in the background (say, an audio player) would suffer. Or that kernel compile (running at nice 20).

(Log in to post comments)

Python slithers into Wesnoth

Posted Jan 15, 2009 23:17 UTC (Thu) by roblucid (subscriber, #48964) [Link]

> Computers getting faster is an illusion

Is it Ted Tso's law that would be something like, no matter how much faster your hardware is, a kernel compile will always take me roughly 10 minutes.

Python slithers into Wesnoth

Posted Jan 15, 2009 23:51 UTC (Thu) by alankila (subscriber, #47141) [Link]

The texture-from-pixmap extension should allow one to use RGBA (or more likely, ABGR) surface which is directly usable by the display hardware for displaying. It's still not as good as something like DirectX which gives memory straight from the graphics adapter for application to use. That being said, it is not such a big problem because texture fill is still insanely fast on any GPU, so it isn't a large problem to require the graphics card to blit it when the image is ready. In contrast, CPU-based data blitting is always terribly slow because of low system memory bandwidth, and can't be optimized in any meaningful way...

As I see it, the trouble with XSHM pixmaps is that they aren't actual pieces of display surface. Something still needs to blit it before it finally is on the screen surface, and for reason or other it always seems to be the main CPU, and not the GPU. I also strongly suspect the XSM pixmaps are physically stored in the system RAM, and not the graphics card RAM. One likely explanation for this is that reading from display RAM by the main CPU seems to be very slow. (You can make this mistake quite easily with DirectX surfaces -- reading from display is a lot like hitting denormal numbers on FPU: suddenly everything begins to crawl...)

So in the end, XSHM may save one copy from application's memory to X server's memory, perhaps, but there are many copies left, all which are dreadfully expensive.

Xvideo indeed is quite marvelous when it comes for displaying data. Unfortunately the U and V channels have lower bandwidth compared to Y, limiting chromatic accuracy. On the other hand, gamma correction is done by hardware, which can be awfully convenient, and you get tint and brightness/contrast correction controls for free while at it. On the whole, I do think that it may be the only reasonable way for displaying video data on X.