At 9:52 AM -0400 8/27/02, you wrote:
>I did this for the Kodak Picture CD (best example is v5.1 now in 
>stores).  Although I can't share the code, it's dynamically-loading, 
>auto-positioning, multi-directional, multiple sizes, drag-n-drop, 
>yada yada yada, and can handle, I guess, thousands of images.  I 
>will give a few clues, though:
>
>- Have actual thumbnails - trying to show a large image in a small 
>space will just give you memory problems (especially on a Mac)

I agree.  I did a similar project & maintained a proplist containing 
the .image thumbnails & the current strings to display under the 
thumbs (in that case #'s), so that as I scrolled, the labels could be 
updated along with the thumbs.

>
>- Do not preload the sprite channels with ALL your images.  This may 
>work for 50 images, but if you get into the hundreds or thousands, 
>you'll never get them all loaded.
>
>- Have a "pool" of displayable channels and reuse them as necessary. 
>This takes some programming work, but is the only way to manage 
>large numbers.
>
>- If you don't need to scroll, but can simply "page" through the 
>pictures, then it's a lot easier because your "pool" is the number 
>of displayable images on screen.  If you need better performance, 
>you could run two or three pools and switch between them - one will 
>be visible, the rest will not (similar to the old page-flipping 
>techniques for video animation).
>
>- Fixed position is easier than dynamic position.  If you know every 
>picture will have a thumbnail no larger than 96 pixels on each side, 
>say, then you can lay them out more easily.  Unfortunately they 
>don't look as good as when dynamically sized (so the same amount of 
>space is between them regardless of whether they are short, wide, 
>landscape, portrait, etc.), but it's more math to do the dynamic 
>sizing.
>
>- If you have a set number of images, that's easy enough, but if you 
>have to insert/delete or drag-drop between them, then you get into 
>another set of management issues.
>
>- Generally I kept all the information in a list (well, a number of 
>lists).  Actually, in the last incarnation of the project I had a 
>pretty elaborate subsystem where everything was objects and an 
>object could be more than just a thumbnail (but I won't get into 
>that here) and the big benefit was that you could do the layout and 
>query each object for its size without having to wait for it to 
>load, because waiting for 1000 thumbnails to physically load takes a 
>LONG time on some systems, and so if you wanted to scroll, I had a 
>placeholder graphic that would serve for the time being.  This way 
>you could immediately scroll to the end, and although the images 
>there hadn't loaded yet you could still move there, and then they 
>would render.  This also entailed building a thumbnail distributor 
>(because we also did multiple sizes (small, medium, large 
>thumbnails).  Involved, but the result was worth it.
>
>So, those are some things to consider - pool of reusable sprites, 
>forward scrolling, preloading (or not preloading), fixed position 
>vs. dynamic positioning, free scrolling vs. paging, etc.  It can be 
>done using a small amount of sprites.
>
>- Tab
>
>At 02:13 PM 8/26/02, Charlie Fiskeaux II wrote:
>>I'm working on an image browser, so that someone can browse through an
>>archive of images and search them via keywords, and I'm trying to decide the
>>best way to create the grid of thumbnails.  So far it seems like the best
>>solution would be using Imaging Lingo to combine all of the thumbnails and
>>their names onto a single large image, but I wanted to see what y'all
>>thought.  The grid will have to be scrollable, since only four rows will be
>>visible at once, and I want it to not have a physical limit on the number of
>>thumbnails it can display (like running out of the 1000 sprite channels).
>>Suggestions?  Comments?
>
>[To remove yourself from this list, or to change to digest mode, go 
>to http://www.penworks.com/lingo-l.cgi  To post messages to the 
>list, email [EMAIL PROTECTED]  (Problems, email 
>[EMAIL PROTECTED]). Lingo-L is for learning and helping with 
>programming Lingo.  Thanks!]

[To remove yourself from this list, or to change to digest mode, go to 
http://www.penworks.com/lingo-l.cgi  To post messages to the list, email 
[EMAIL PROTECTED]  (Problems, email [EMAIL PROTECTED]). Lingo-L is for 
learning and helping with programming Lingo.  Thanks!]

Reply via email to