[Gzz] Re: Imagecache

[Tuomas Lukka]

On Fri, Sep 13, 2002 at 06:01:13PM +0300, Tero Mayranen wrote:
> On Fri, 13 Sep 2002, Tuomas Lukka wrote:
> 
> > 1) Why are you not using STL:s containers?
> > Doing linked lists by yourself is not nice: too much code,
> > as well as error possibilities.
> 
> I suppose I underestimated the amount of code needed for a linked list, as
> well as the error possibilities...  

Yes, I know the feeling

> So OK, the code is a mile shorter now
> that it's using the STL list.  

Excellent!

> But when moving an image to the top of the
> "recentlyUsedImages" -list, the item has to be searched from the list
> first. It used to be enough to just use the "next" and "prev" pointers
> when the linked list was "coded into" the own class. But hopefully that
> won't matter in performance.

Shouldn't be too bad. Especially since you can use a tree.

> > 2) Doc++ documentation is completely missing. This is not a good thing.
> > Reading this I can't be sure what the external API is supposed to be.
> 
> Yep, sorry, at the moment it has even less comments. Anyway, the key calls
> of the external API are:
> 
> GdkPixbuf *getImage(string URX, int LOD)
> 
> Where string URX is an URL or URN or whatever universal resource naming
> scheme the upcoming Java-loader will support =), int LOD is the minimum
> level of detail that you'd like to have, and the return value is whatever
> GdkPixbuf happens to be available. It might even be a smaller resolution
> than you asked for (in which case the cache starts loading a bigger
> resolution). Use (int)gtk_object_get_user_data() to get the LOD of the
> image...

I've been thinking about this: maybe we actually should not use
GdkPixbuf at that point of the API but OpenGL textures, or even
Mosaic::TexRect 's.

> int cropToSize(int maxSize)
> 
> Which deletes the biggest resolutions of the least recently used images
> until the size of the cache is smaller or equal to maxSize.  It returns
> the size of the cache.

Ouch, a terminology problem: cropping usually means cutting away
parts of the image. Also, need to decide on a scale and stick to it.
Possibilities:

        0 = normal resolution
        1 = normal / 2
        2 = normal / 4

                + used by OpenGL
                - doesn't tell about image size, so anyone calling
                  "cropToSize" or whatever it's renamed to
                  will have to know

        kilobytes

                + handy for knowing how much there is
                - bad for resolutions: some images need more than others.

And then call it always size or LOD or whatever.

Still, please insert these as docxx (exactly like javadoc) comments
right away.

> > 3) Caching the image in memory at all resolutions is really bad:
> > OpenGL does have the SGIS_generate_mipmaps extension, which should be
> > used. This way, you should only have the largest image in memory,
> > and scale down when it has not been used for a while.
> 
> OK then, now it works like that...

Good work.

        Tuomas