Re: image cache

[Chetan Pandya]

I looked at this some more and looks like it is not so everywhere. However, 
there seem to be more problems. It isn't clear how this is organized. For 
examples images are shared across frames, but there is no reference counting to 
know when it can be refreshed without affecting other frames and when it 
cannot. 


--- On Tue, 12/16/08, Chetan Pandya <address@hidden> wrote:

> From: Chetan Pandya <address@hidden>
> Subject: Re: image cache
> To: "Chong Yidong" <address@hidden>, "Miles Bader" <address@hidden>
> Cc: "Eli Zaretskii" <address@hidden>, address@hidden, "Stefan Monnier" 
> <address@hidden>, address@hidden
> Date: Tuesday, December 16, 2008, 4:56 AM
> --- On Tue, 12/16/08, Miles Bader <address@hidden>
> wrote:
> 
> 
> > Chong Yidong <address@hidden> writes:
> > > Note that fixing requires changing all the
> functions in image.c that
> > > require a frame argument, so that they use a
> terminal argument instead.
> > > Otherwise, if you associate image caches to
> terminals, you run into
> > > problems with terminals that have no frame (e.g.
> terminals created using
> > > x-open-connection), because you can't supply
> those image functions with
> > > a frame argument.
> > 
> > Frameless terminals can't use those functions
> currently
> > anyway, right?
> > 
> > So one could change the current implementation to put
> the
> > cache in the
> > terminal data structure, but preserve the current
> > interfaces.  This
> > would yield more sharing, without losing
> functionality.
> 
> Isn't that how it is currently?
> 
> From frame.h:
> /* Return a pointer to the image cache of frame F.  */
> #define FRAME_IMAGE_CACHE(F)
> ((F)->terminal->image_cache)
> 
> Chetan
> > 
> > -Miles
> > 
> > -- 
> > You can hack anything you want, with TECO and DDT.