Removed unused data member selRow.
Keep reference to LinkApp instead of pointer.
Call LinkApp::getSelectorBrowser once and store result.
Renamed fontheight to fontHeight.
Use iY consistently: store the item's y-coordinate in it.
This operation is not so slow that it really needs caching. Also
reducing the delay before showing a directory will have more impact
on the user experience than a slightly faster paint.
The way the caching was implemented was rather problematic. Also I'm
not convinced caching is useful at all. So I removed it. If at some
point we decide that caching is a good idea, it would be best to
re-implement it from scratch, so nothing of value is lost by removing
the existing caching code.
One problem was that the prepare method would check the existence of
a screenshot file for every file in the directory, which adds to the
noticable delay before showing a directory which holds many files.
Another problem is there was no upper limit to the number of
screenshots that would be cached. On directories with many screenshots
the memory use could rise to several hundred megabytes, which can be
problematic on some of the systems we want to support.
Also there was a rather nasty hack present to ensure screenshots were
loaded without an alpha channel.
My main doubt about the usefulness of screenshot caching is that
caching will only speed up the showing of an image from the second
time onwards. In typical use, the average screenshot is displayed at
most once. If the image load time is long enough to annoy the user,
any real solution would have to work also for the first showing.
For example, background (asynchronous) loading could be implemented.
