LWN: Comments on "Interview: Jim Gettys (Part I)"

Why not have X-Windows store the COMPRESSED image?

k8to — 2006-07-05T01:52:33+00:00

Great. You're pedantically correct.

However, knowing this, we non-pedantic long-time Unix users still call it X Windows all the time, along with other names.

Interview: Jim Gettys (Part I)

nhippi — 2006-07-03T11:52:10+00:00

> The Marvell wireless chip, which has an ARM 9 and 92K of RAM, can forward packets in the mesh network while the processor is suspended to RAM. This capability has been demonstrated in the lab, and Michail Bletsas is confident of the outcome; in fact, it was an actual demonstration that convinced us to use Marvell. Other wireless vendors lack this capability.

This is incorrect. Prism54 and it's newer versions by conexant have a arm9 and 64K Of RAM (fullmac chips had even more). There is even a reverse engineering project to run your own firmware on it:

http://jbnote.free.fr/islsm/doku.php?id=documentation:isl...
http://prism54.org/freemac.html

> In most areas, we're still pedal to the metal on basic problems like device drivers, and finishing up LinuxBIOS + Linux as boot loader so that we can support installation over the (mesh) network.

I hope OLPC isn't tying themself too tightly to X86 and geode platform.

Firefox?

Lovechild — 2006-07-02T21:11:58+00:00

Firefox are you entirely on the level here Jimbo?

Firefox being not only a shitty application with poor UI design and hidious memory/CPU use, it's not easily slimmed down. KHTML (or gtk-webcore) with a custom UI would be a much saner choice, maybe looking at what Nokia has been doing with the wonderful 770 device. With a small screen we need to make the most of it and the 770 has really shown that it is possible to design applications on small devices with full functionality.

Anyways on to business, Philip Van Hoof' tinymail project might fill your email niche, it uses next to no memory and is deadfast. Not only is this a wonderful project in itself but Philip is developing it as a pace that can only be explained by having caffine directly injected into his bloodstream.

Finally I want to thank you for picking Red Hat as your technology partner in this venture and helping the free software community think about the lofty goals we should set for our work.

I am, of course, a pledger to buy one at overprice to help children get education.

- David Nielsen

Why not have X-Windows store the COMPRESSED image?

giraffedata — 2006-07-02T07:30:13+00:00

There's no such thing as X-Windows. There's X (full name: The X Window System) and there's Windows (Microsoft).

Why not have X-Windows store the COMPRESSED image?

oak — 2006-06-29T20:50:15+00:00

> Personally I think more use should be made of the XShm extension,
> when the client stores the images in shared memory and the X server
> can see them. One thing graphics processors can do is blit images
> and convert colour and layout on the fly.

The X client memory is main RAM on the machine, X server memory
is (partly) memory on the graphics card. I.e. at least the graphics
needs to be copied from the client SHM memory to the gfx card memory
before blitting on screen. However, I don't think this is an issue
compared to the issue of app keeping images redundantly in memory and
making the whole machine swap...

Probably one reason why apps store so much images to the X server
is that this way the images can be blit much faster when the app
is using X server remotely. Faster networks make copying image data
from the remote client to X server less of an issue but maybe with
server side images there's less latency? (which is the real killer
of UI responsiveness with remote X)

> I think what would really help is a way to see what pixmaps
> (and other resources) are currently stored in the server.
> That would make it easier to see if anything is being leaked.

There is already a such thing. There's a patch to the X resource
extension and simple utility for showing the listed pixmaps.
It was mentioned in one of the optimization blogs I think.

Btw. For measuring application response times (e.g. to see whether
performance optimization had an effect), there's a tool called
"xresponse" (it outputs timestamped "X damage" i.e. screen updates
events).

Firefox?

nix — 2006-06-29T14:49:21+00:00

xulrunner cuts down disk space requirements, but it'll only cut memory usage down if you have both running at once.

Interview: Jim Gettys (Part I)

smitty_one_each — 2006-06-29T11:13:39+00:00

I'm thinkin' a six pack o' them gadgets would be a great way to do a first compile-farm project.

Firefox?

drag — 2006-06-29T10:34:30+00:00

If your going to run firefox then thunderbird may be a good choice for email and such.

If they get that xulrunner stuff going well then that should cut down on the size and hopefully the memory requirements of both applications(, correct?)

Firefox?

kleptog — 2006-06-29T10:12:19+00:00

I feel your pain. I have a 128MB machine which was running fine on Debian Sarge. I've upgraded some stuff to see if there have been some worthwhile improvements. Instead I get around the same features but now it swaps all the time. The phrase "hemorrhaging memory" really hit home. I honestly don't know what could take 118MB of memory just to have a few tabs open.

Why not have X-Windows store the COMPRESSED image?

kleptog — 2006-06-29T10:08:01+00:00

The big problem is that these images are stored so they can be quickly blitted to the screen. What graphics cards do you know that support lossless compression on images. Many would support JPEG/MPEG style, but lossless compression is a pain. Especially when you're going to want to read individual pixels from it (consider if a window partially overlaps the image you want to display).

Personally I think more use should be made of the XShm extension, when the client stores the images in shared memory and the X server can see them. One thing graphics processors can do is blit images and convert colour and layout on the fly.

I think what would really help is a way to see what pixmaps (and other resources) are currently stored in the server. That would make it easier to see if anything is being leaked.

Firefox?

jg — 2006-06-29T09:57:36+00:00

Firefox yes,

Evolution, no.

We need a good browser, but Evo is way to complicated (and huge) to be
considered.
Regards,
- Jim

Interview: Jim Gettys (Part I)

jg — 2006-06-29T09:56:19+00:00

Convincing isn't the issue.

We're focused right now on getting the kids machine out, and what
others have done on our behalf is sufficient.
Regards,
- Jim

Interview: Jim Gettys (Part I)

jg — 2006-06-29T09:54:29+00:00

Yes, there is already such a web site.
Regards,
- Jim

Why not have X-Windows store the COMPRESSED image?

jg — 2006-06-29T09:52:55+00:00

It is a good question.

Care to work on a compressed image transport extension? Then storing
compressed images in the server would probably be straightforward.

I warn you that the last time this was attempted, that the people doing
XIE slipped down the slippery slope into complexity hell, to the point that
XIE is no more.

None the less, it is on the list of things I'd like to see/have: care to work on it?

BTW, on a local machine, moving the images is *really* fast. Just clock
it sometime.

Firefox?

wstephenson — 2006-06-29T09:15:41+00:00

Presumably they want to use OLPC as a driver to get Firefox and Evolution
slimmed down and suitable for low memory devices. Sorrow and weep, RAM
vendors of the world! They could just consider existing small
footprint solutions such as KHTML or KOffice from the KDE stable; other
alternatives exist.

Firefox?

job — 2006-06-29T08:42:41+00:00

I have a laptop with 128MB RAM and Firefox in completely unusable in every way. What were they thinking? Why not go with KHTML? Or some embedded browser like Dillo?

Why not have X-Windows store the COMPRESSED image?

guinan — 2006-06-29T02:41:14+00:00

There was an X Image Extention (XIE) some time ago, which basically
did what you're describing, but it got deleted from the tree in
X11R6.7.0.

I googled but couldn't find a definitive reason why it was deleted,
but I gather it wasn't popular with some developers.

Why not have X-Windows store the COMPRESSED image?

dlang — 2006-06-29T02:20:55+00:00

what compression algorithm are you thinking of useing?

remember that for this you have to use a lossless compression, and those are famous for having different behavior on different sets of data.

however, the real problem is that X is doing exactly what it's been told to do. programs should know what images are worth keeping anround and which ones aren't, too many of them default to keepign lots of things around and never useing them.

it may be an interesting thing to explore storing these pixmaps on the video card itself, I don't know if the current X drivers can support this or not.

Interview: Jim Gettys (Part I)

dododge — 2006-06-29T00:33:21+00:00

wonder if they've considered making these available to the developed world at inflated prices, to subsidize the developing world machines.

Since late last year there's been an effort to drum up support for doing exactly that. Bear in mind this has no official involvement with OLPC; it's just an attempt to convince them that there's enough of a market to make them available.

Interview: Jim Gettys (Part I)

gjmarter — 2006-06-29T00:14:59+00:00

A commercial version has certainly been discussed.

Interview: Jim Gettys (Part I)

drag — 2006-06-28T23:00:14+00:00

I HOPE so.

Because I realy realy realy freaking want one of these things and I don't want to get it from some bozo stealing laptops from children to sell on ebay.

Interview: Jim Gettys (Part I)

allesfresser — 2006-06-28T22:00:59+00:00

I wonder if they've considered making these available to the developed world at inflated prices, to subsidize the developing world machines. It would help the economy of scale, too. As long as they keep with the priority being the developing world (i.e., they ignore requests for features that would be useless to the kids in the village), it might be helpful. (Maybe?

Why not have X-Windows store the COMPRESSED image?

Yorick — 2006-06-28T21:58:59+00:00

That would certainly decrease memory usage but perhaps not at much as regenerating the
pixmaps. A compressed image is just a subroutine written in a very compact language
specialised for generating broad classes of images. The application's own code and data to
regenerate the pixmaps are in most cases already in memory, and the code can usually be more
efficient than a compressor would be as it is adapted to its purpose.

I could definitely imagine compressed pixmaps being a useful way to lower the memory
requirements of existing applications. It just needs some heuristics to avoid compressing those
used frequently.

On a lower level, compressing memory pages that would normally have been swapped out to
disk could make sense on a swapless machine. (This could be an interesting kernel project.)

Why not have X-Windows store the COMPRESSED image?

allesfresser — 2006-06-28T21:56:28+00:00

Possibly the compression and decompression would eat a lot of CPU, and therefore power, which would be bad. I could see that being the case, especially if there's a lot of not-very-compressible pixmaps floating around.

Interview: Jim Gettys (Part I)

faassen — 2006-06-28T21:09:46+00:00

Fascinating stuff! I'd like to see more interviews like this. If they can get the mesh networking to work with a long battery life, all kinds of interesting social effects will start happening once this gets into enough people's hands. (and I want one of course!)

Interview: Jim Gettys (Part I)

cventers — 2006-06-28T20:45:35+00:00

KHTML is light and easy, which is why Nokia was working on it a little
while ago :)

In all seriousness, I think the OLPC project is fantastic, and very much
thank anyone contributing to it.

Why not have X-Windows store the COMPRESSED image?

dwheeler — 2006-06-28T20:16:51+00:00

One question, maybe the interviewer can ask Gettys - why not just have X-Windows store the COMPRESSED image? He notes that "many applications seem to think that storing pixmaps in the X server (and often forgetting about them entirely) is a good strategy, whereas retransmitting or repainting the pixmap may be both faster and use less memory.", and he mentions Federico Mena-Quintera's work. But if they're stored in the client, and sent each time to X-Windows, you now have to at least resend... and X-Windows isn't always local; over a mesh in particular you DON'T want the image retransmitted each time. If you have to store it anyway, why not have X-Windows store compressed, not uncompressed images? Indeed, if X-Windows could accept common compressed formats, and recompress when it feels like it, it could have all the memory benefits he notes...!