Re: gtk+ and gtk-engines slow

[raster redhat com]

On 23 Jan, Jeff Garzik scribbled:
->  On Sat, 23 Jan 1999 raster@redhat.com wrote:
->  > On 23 Jan, bratsche@dfw.net scribbled:
->  > ->  So when you're running the pixmap theme and set a button pixmap to
->  > ->  button.png, does each application keep track of its own button.png file?
->  
->  > yup. due to the fact thats its a bitch to share large chunks of
->  > constantly chnaging memory between apps.
->  
->  Not really; I did this when I was doing a lot of news server-related
->  coding.  The problem then was analagous -- I had to store NNTP messages
->  (average size = 2-4K or so, max size 5M or more sometimes) for short
->  periods of time in shared memory, so that various processes
->  could do their work.

well this si different i have to store possibly large chunks of memory
(100kb -> 10Mb) and lots of them and have them shared for long periods
of time with possibly lots of applications.

now we hit problems: 
MIT-SHM: limit 128 shm id's, also on some os's an dhm chunk size is
limited.

mmap files: mmap of /dev/zero and fd sharing is great but seesm from
the reports i read to have issues.mmaping a single file would mean
being able to share an arbitarily large chunk of memorybetwene apps BUg
it would mean relying on the flingy system to NEVER sync the file to
disk for performance reasons.

->  The solution was to create one big buffer, and manage it cooperatively
->  using semaphores and mutexes.  In essense, you create your own malloc
->  which grabs a buffer of shared memory.  It was a cyclical buffer, so
->  that messages (or pixmaps in this case) expired when they were
->  overwritten by the newest incoming message -- or pixmap in this case.

well pixmaps are alrayd server-side, BUt it's necessary that pixmaps be
issued and arbitrated by a 3rd party daemon due to X's refcounting
scheme for pixmaps - this daemon must never quit. it mayaswell handle
the management of the image data (origicnal 24bit) itself too - so we
end up wiht an imlbi daemon - all clients request it to load images and
render them - if a client wants access to the image data istelf it has
to explicitly request i and then and only then will it be shared out,
until the client indicates it is done wiht the data. So to put it
simply i need tomake a big daemon, woith good IPC.

->  The one downside to this approach (which I didn't have to worry about in
->  my experiment NNTP server) is that if refcounting breaks down, you have
->  to manually clean the IPC shm segment list. 

yup.:) sux - doesn't it? i use rmshm often :)

->  	Jeff

-- 
--------------- Codito, ergo sum - "I code, therefore I am" --------------------
raster@rasterman.com       /\___ /\ ___/||\___ ____/|/\___  raster@redhat.com
Carsten Haitzler           | _ //__\\ __||_ __\\ ___|| _ /  Red Hat Advanced
218/21 Conner Drive        || // __ \\_ \ | |   \ _/_|| /   Development Labs
Chapel Hill NC 27514 USA   ||\\\/  \//__/ |_|   /___/||\\   919 547 0012 ext 282
+1 (919) 929 9443, 801 4392   For pure Enlightenment   http://www.rasterman.com/

              \|/ ____ \|/  For those of you unaware. This face here is in fact
	      "@'/ ,. \@"   a Linux Kernel Error Message.
	      /_| \__/ |_\
		 \__U_/