[Gzz] Re: ImageCache

[Tuomas Lukka]

On Tue, Sep 17, 2002 at 09:25:25PM +0300, Tero Mayranen wrote:
> On Fri, 13 Sep 2002, Tuomas Lukka wrote:
> > 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.
> 
> Why not, TexRects seem to be easy to transport over the JNI interface...
> But how does one create a TexRect from pixel data?

Ok, here we come to the important point: where should we actually store
the pixel data. There's a real problem with the current libmosaic (which
we won't fix before tomorrow's demo): it stores all image data twice,
in very wasteful formats.

See how GZZGL.Texture now loads an Image as a subimage. What we should
do is to load the image into a texture and use it from there, not storing
it in memory.

But another problem presents itself: at least NVIDIA's driver is not 
smart enough to use only the mipmap levels above TEXTURE_BASE_LEVEL
but loads all to the GPU. This means that we need both high and low resolution
versions of the same texture to be able to keep up speed.

> > Ouch, a terminology problem: cropping usually means cutting away
> > parts of the image.
> 
> True, cropToSize was actually dropToSize first but I thought that sounded
> bad too =)...  Currently it's trimToSize.

trim sounds the same as crop. drop has the right meaning.

> > 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.
> 
> hmm whenever LOD is referred to it means and works just like the first
> description.  The trimToSize call is for the whole cache and it takes the
> size in bytes.  The byte-size of images is stored in them too...

Ok, then it should be dropToLOD.

        Tuomas