[Gzz] 911

[Tero Mayranen]

On Tue, 10 Sep 2002, Tuomas Lukka wrote:

> Loading at different resolutions?

That was on the ImageCache level - there would've been a separate
CachedImage for each different resolution. I changed that now, there's a
class for each different image and another class for each resolution.

> > |CachedImage images[]           |
>
> This should be a map, not an array

Sorry, bad design document: in the implementation it was a linked list
actually =/.. But now, in the ImageCache there's a map of the different
images, and each of those images has a map of the resolutions, so it's
easy to look up a given URL and a given LOD. But also, all the different
resolutions are in a linked list in the ImageCache - so the least recently
used ones can be easily found and removed...

> Umm, how is the threading going to work here?

Backgroundloader extended Background.java and I thought it would work by
calling addTask with a new Runnable that does the http-loading and
writing, but now I realize Background.java just does stuff in a queue
and not "simultaneously"...  I guess Backgroundload should just start the
Runnables itself?  (Sorry the Runnable didn't show up in the ascii-UMLs!)

Anyway I think the biggest of the "million little things" was probably the
whole logic of the ImageCache::getPixbuf call.  But here's how it goes:

Try to get the wanted Image.
If the wanted image was not found, start loading and return the
loader-image.

If the wanted image was found, try to get the wanted resolution.
If the wanted resolution was not found:

    Try to find a fully loaded bigger resolution, if found: resize it and
    return. (this resolution will be considered fully loaded)

    Try to get a partially-loaded image from the loader.
    (this resolution will be considered not fully loaded)

    Try to find a smaller resolution, if found: resize it and start
    loading a better resolution and return the blown-up image.
    (this resolution will be considered not fully loaded)

    If we got here then the loader doesn't have enough data yet to
    determine the size of the image: return the loader-image.

If the wanted resolution was found: Check if it's fully loaded.

If the wanted resolution was not fully loaded:

    Try to get a partial version from the loader.

    Try to get a fully-loaded bigger resolution.

    If we got here then the loader doesn't have enough data yet to
    determine the size of the image: Return the loader-image.

And finally if the wanted resolution was fully loaded, then return it.

Every time a wanted resolution is found or created and returned, then it
will be moved to the top of the recently used-list.

The GdkPixbufLoader signals the ImageCache when an image has been loaded:
then the image will be copied to the full-size (LOD 0) resolution and
considered fully loaded.

I guess the next weirdness is using the JNI backwards, to call the
BackgroundLoader from C++...

--
tero