[Gzz] Re: Imagecache

[Tero Mayranen]

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...  So OK, the code is a mile shorter now
that it's using the STL list.  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.

> 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...

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.

> 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...

--
tero