Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>I'll complement the answer by skamradt with an attempt to design this for being as fast as possible. For this you should</p> <ul> <li>optimize I/O</li> <li>use multiple threads to make use of multiple CPU cores, and to keep even a single CPU core working while you read (or write) files</li> </ul> <p>The use of multiple threads implies that using VCL classes for the resizing isn't going to work, as the VCL isn't thread-safe, and all hacks around that don't scale well. <a href="http://www.efg2.com/Lab/Library/ImageProcessing/Algorithms.htm" rel="nofollow noreferrer">efg's Computer Lab</a> has links for image processing code.</p> <p>It's important to not cause several concurrent I/O operations when using multiple threads. If you choose to write the thumbnail images back to files, then once you have started reading a file you should read it completely, and once you have started writing a file you should also write it completely. Interleaving both operations will kill your I/O, because you potentially cause a lot of seeking operations of the hard disc head.</p> <p>For best results the reading (and writing) of files should also not happen in the main (GUI) thread of your application. That would suggest the following design:</p> <ul> <li>Have one thread read files into TGraphic objects, and put these into a thread-safe list.</li> <li>Have a thread pool wait on the list of files in original size, and have one thread process one TGraphic object, resize it into another TGraphic object, and add this to another thread-safe list.</li> <li>Notify the GUI thread for each thumbnail image added to the list, so it can be displayed.</li> <li>If thumbnails are to be written to file, do this in the reading thread as well (see above for an explanation).</li> </ul> <p><strong>Edit:</strong></p> <p>On re-reading your question I notice that you maybe only need to resize one image, in which case a single background thread is of course enough. I'll leave my answer in place anyway, maybe it will be of use to someone else some time. It's what I learned from one of my latest projects, where the final program could have needed a little more speed but was only using about 75% of the quad core machine at peak times. Decoupling I/O from processing would have made the difference.</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload