Re: need a thumbnail browser without memory limitations

Hi Peter,

The point is you need to be managing the memory. One way is to push you app to the upper limit and handle errors (hopefully). A more conservative approach as I suggested earlier is to consider a viewport design where you are concerned with a page or data at a time. You can preload the next page. You need to tune this to the way the user scrolls. That is if they are rapidly scrolling through pages without pausing don't paint the pictures. If they are using small scroll you can allow for acceleration on that, but consider that always as a request to display all pictures.

Some pseudo code to explain:

Class PictureManager

Private _loadedItems as LongQueue ' create a queue type wrapper for an array. FIFO : first in, first out.

Private _files() as String ' this holds all the files
Private _pictures() as StdPicture ' use what you want here, IDB, Bitmap, etc

Public Function GetItems (startFrom, count) as StdPicture() 'VB6
For i = startfrom to startfrom + count - 1
Check to see if _pictures(i) Is Nothing
If it is nothing, then check the memory pressure which might be a user set max memory (default to say 500 MB) divided the rough size of each thumbnail versus the count of how many are in the queue (already cached)
If needed, pop the first item off the queue, check to see it's not within range (you'll need to do some math to calculate if the range of say 3 times requested count per page is within memory limit and adjust as needed.) By removing the oldest item (FIFO), you are less likely to need to load that one again. But check if it is in the range of the current viewport page and the desired level of cache. If it is, then push it back on, and pop the next one off until you get a picture you can dispose of then set _Picture(idx) = Nothing
Now that you have memory space, create the new thumbnail, and push it's index onto the queue.
'repeat till finished.,

The issue you have with this kind of approach is the lifetime of the objects returned from GetItems. StdPictures or COM objects are fine in one way as you can safely set your reference to them as nothing in the PictureManager. It however won't release that memory requirement until any other code that has a reference to them does. If you use API approach then you have to be very careful and shouldn't really pass them out at all because you won't have reference counting rather you should do the painting from inside your picturemamager; either that or wrap the DIB's inside a class so as you do have reference counting.

And the other part is to allow for scrolling, you should try to precache the next and subsequent pages. This is where threading would be really helpful. You can use a timer, but ensure you yield a LOT using DoEvents and definitely to NOT put any sleep statements in the timer's code as you will just be slowing down your app (yes believe it or not some folks around here actually recommend putting sleep in after DoEvents statements in loops. Don't listen to them !!) In your timer, you'll need to also be ready to cancel or adjust what you are preloading if the viewport position changes.

If you are really after good visual performance though you really need to be looking at direct draw. I think you'll find most picture/photo manager software these days uses that. Then again it depends on what you want to do with the pictures once you have them displayed as well.








"Peter" <peter_l@xxxxxxxxxxxxx> wrote in message news:ghm2qr$js1$1@xxxxxxxxxxxxxxx
Yes, I still don't know whether I will limit my app to 5000 thumbnails and have fast perfomance or whether it will have no limits on the max. amount of thumbnails but have slow performance(on the fly concept).
For solution #1(limit to 5000pics) I understand that I load my jpgs into a DIBSection, shrink them using StretchBitBlt to 400X300 and then draw them onto a Form or a single picturebox or whatever. Question: How do I move a drawn picture if the user resizes the form? Do I need to erase it and redraw it somehow?
And would my(novice) idea work to load 5000 pictureboxes, leave them empty but draw the DIBs onto them to for easy movement and receiving click events?
Seems that is a very stupid idea because you didn't comment on that?

For solution2, Larry's code could be a good start point but I need to test whether the low performance due to reloading in Form_paint() is still acceptable for me?

So what about solution#1? How do I manage the drawn DIBs in my thumbnailbrowser?

Sorry when asking stupid questions, I think I haven't fully understood how to deal with DIBs.

Pegards
Peter




"Larry Serflaten" <serflaten@xxxxxxxxxxxxxx> wrote in message news:Ox2a$dgWJHA.1328@xxxxxxxxxxxxxxxxxxxxxxx

And if you are loading pictures on the fly, there is no point to
convert them to DIBs.

The conversion to DIBS was from when he wanted to create and save to memory thumbnails of all the jpg files he was dealing with, because he wanted to draw those thumbnails extremely rapidly. He has still not made his mind up on whether he still wants to do that, although I have advised him against it.

Mike





.

Relevant Pages
Loading