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) - 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!]
