CLIM mail archive
[Prev][Next][Index][Thread]

Re: CLIM 1.1

Scott McKay writes:
 >    That is, I want to read a raster in from a file, display it, and then
 >    when I want to show another raster I'd like to minimize the amount of
 >    new space I need to use (and to minimize GC).
 > 
 > Ooh, that's a good one.  The short answer is: you can't.  The problem
 > is that CLIM is magically doing you a performance favor, in that it
 > caches decoded inks (including patterns) so that you can redraw using
 > the same ink quickly.  This will shaft you, because CLIM will think
 > you are drawing with the same pattern, but what you want is to reuse
 > the same EQ pattern object.
This is only one of several important places in clim where the
programmer is given no control over CLIM's caching of data - inks in
general, but even other heavyweight objects each either have no
"decache" protocol, or have their own generic function.  

I'd argue that the right thing to do is to add a new gfn
"decache-object" or somesuch which simply flushes and cached state
(including server state) associated with the object (i.e. it would be
a no-op if the CLIM implementation doesn't cache anything).  I'd
expect to be able to use the object again with *or* without
modification in the same context, with the understanding that I'll pay
a price the next time it is actually used.  EG, for colors, this would
free the server colorcell (on a palette-based display)...  Similar
functions already exist for ports, pixmaps, applications and frames
(albeit all under different names).

Until CL specifies an object-destruction protocol (and vendors
implement it), programmers need to have access to these "hints" in
order to write well-behaved systems.

cheers,
	-Michael Thome (mthome@bbn.com)
Follow-Ups: References:
Main Index | Thread Index