[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Gzz] Re: Imagecache
From: |
Tuomas Lukka |
Subject: |
[Gzz] Re: Imagecache |
Date: |
Fri, 13 Sep 2002 19:52:31 +0300 |
User-agent: |
Mutt/1.4i |
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
- [Gzz] 2nd, Tero Mayranen, 2002/09/02
- Re: [Gzz] 2nd, Tuomas Lukka, 2002/09/06
- Re: [Gzz] 2nd, Tero Mayranen, 2002/09/09
- Re: [Gzz] 2nd, Tuomas Lukka, 2002/09/10
- [Gzz] 911, Tero Mayranen, 2002/09/11
- [Gzz] Re: 911, Tuomas Lukka, 2002/09/11
- [Gzz] Imagecache, Tuomas Lukka, 2002/09/13
- [Gzz] Re: Imagecache, Tero Mayranen, 2002/09/13
- Re: [Gzz] Re: Imagecache, Benja Fallenstein, 2002/09/13
- Re: [Gzz] Re: Imagecache, Tero Mayranen, 2002/09/16
- [Gzz] Re: Imagecache,
Tuomas Lukka <=
- [Gzz] Re: ImageCache, Tero Mayranen, 2002/09/17
- [Gzz] Re: ImageCache, Tuomas Lukka, 2002/09/18
- Re: [Gzz] 2nd, Tuomas Lukka, 2002/09/10