Follow Slashdot stories on Twitter

 



Forgot your password?
typodupeerror
×
X GUI

What's the Fastest X11 Image Format? 6

Spirilis wrote in with this query: "Hi, I was wondering what the fastest image format that can be used by X11 is, or more specifically, with Imlib and gdk_imlib. Reason is, I'd like to take my favorite GTK theme and change all the images to the fastest format that X can handle, so gtk-based windows open up quickly; I've noticed with some themes just the creation of windows is viewable as it draws all the images and stuff. For that reason I'd like to convert the images to something more efficient. I'm thinking PPM, or maybe even XPM, but definitely not a compressed format like PNG or GIF or JPEG. Any ideas?"
This discussion has been archived. No new comments can be posted.

What's the Fastest X11 Image Format?

Comments Filter:
  • I've spent a few hours this week perusing the Imlib source code (I want to add my own image format, like the multigradients in WindowMaker, for use in GTK themes)

    Image compression, etc. is only of importance when an image is first being loaded - after that point all the image data is cached, essentially in 24bit color uncompressed.

    If you're on a slow system, there might be some lag when pixmaps have to be resized - basically, when GTK needs a pixmap for a button or window of a size that hasn't been requested before, Imlib won't have a cached pixmap of that size and will have to rescale one on the fly. The default rescaling algorithms are pretty nice quality, too; I think you can set Imlib to use cpu-cheaper ones.

    If the lag is really Imlib's fault, try running imlib_config, increasing cache size if you have the RAM to spare, and tweaking things like that.

    There are more likely possibilities, though:

    GTK+ is supposed to be a fairly lightweight toolkit, but I don't know how optimized it is with themes to consider. When I hot-key flicker between desktops running GTK+ apps, for example, all the pixmap backgrounds come up instantly, but there's a perceptible delay for text to be written on top of them.

    XFree86 is the second most inefficient piece of software (next to Netscape) on a typical Linux system. This is in no way an attack on the XFree developers; they're coding a system that is at the same level of complexity as the kernel, with a lot less publicity and thanks. Short of avoiding poorly accelerated video cards or waiting for XFree86 4.0 (with DLL-based hardware support, revamped XAA, and lots of other goodies) I don't know what you could do about this one.

    I wish the XFree86 people would provide anonymous CVS access. They bemoan a parcity of developers, but they're hardly doing much to attract new blood when all the cool new work is being done behind closed doors. Most latecomer developers to a project don't suddenly wake up one morning and think, "Gee, I want to pledge a massive contribution of time and effort to project X," (pun intended), they instead start by downloading code as bleeding edge as possible to make a few little hacks and tweaks on while getting to know the system. Having to wait months at a time between software releases, with nothing but rumors publicly available inbetween, isn't conducive to this kind of tenative engagement.

    They have their reasons [xfree86.org], of course; I just think those reasons are outweighed by the benefits of more public development.

    Wow, that was a nice rant. Hope I get more "Interesting" than "Offtopic" votes; both probably apply.

    The answer to your question is: file format loading times only matter to Imlib once, when the file is loaded. Efficiency while Imlib is actually rendering pixmaps is file format independent.
  • There is a benchmark page at http://www.rarcoa.com/~thebard/X11-performance.htm l that gives some basic Xmark scores for various cards.

    These scores still lag quite a bit behind Xig's Accelerated X, and are completely blown away by an HP Visualize fx6, which posts an Xmark of 53.

Without life, Biology itself would be impossible.

Working...