Excessive X server size

[Keith Packard]

On Wed, 2006-06-07 at 15:00 -0400, Adam Jackson wrote:

> I don't know of anyone actively working on anything in this space.  It's 
> definitely an interesting area of research though.

I'd say the real problem is that uncompressed images are huge, and
decompression is (now) reasonably efficient (and helps sell more x86 cpu
cycles). We can do a couple of things:

 1) Support compressed images in the server using the nascent read-only
picture support in Render.

 2) Get the images out of the X server entirely, using MIT-SHM for image
transport and leaving them in the client's address space. Hack up the
MIT-SHM client side to touch every page of the image before pushing the
request to the server so the server doesn't end up faulting the image
into memory as it displays it.

 3) Both. Use shared memory to hold these read-only images.

-- 
keith.packard at intel.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://lists.x.org/archives/xorg/attachments/20060607/c06536e4/attachment.pgp>