CLIM mail archive
[Prev][Next][Index][Thread]
CLIM 1.1
References: <199403241812.NAA09550@pravda.cc.gatech.edu>
<19757.9403242330@tigris.harlequin.com>
Date: Fri, 25 Mar 94 13:01:16 EST
From: mthome@BBN.COM
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.
Heavyweight objects such as ...?
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).
I agree that having a color-destroyer would be useful.
They are all undert different names because they do different things.
The fact that they all happen to deallocate some storage is just one
minor detail.
References:
Main Index |
Thread Index