SDK: photo:requestJpegThumbnail slow if thumbnails not already exist

[sb-x]

I noticed photo:requestJpegThumbnail being rather slow in situation, where developSettings have been recently applied to the images and Lightroom did not calculate previews yet or for example if you export some images as a new catalog and do not embed any smart previews or alike. When you load this freshly exported catalog that only links to the raw files (and in my case has some sliders applied - not sure if that is important) and does not yet come with pre calculated previews, calling photo:requestJpegThumbnail() takes a long time before it calls the callback. I did some measurements and for me it takes roughtly 2x as long as running a full export via LrExportSession for that photo.

This seems like a bug to me, as i would expect the JpegThumbnail to be rendered faster than a full export.

As a side note: once we request the thumbnail, Lightroom is using CPU for building the thumbnail even if we no longer keep a reference to the thumbnail request. The callback won't be called anymore but Lightroom keeps busy until it managed to render the thumbnails. So once you made a call to photo:requestJpegThumbnail() there is no way back, you will have to wait for Lightroom to finish its calculations before it will be responsive for further operations.

Tested on macOS and windows with newest LrC 14.2 (similar behaviour since earlier versions too).

[johnrellis]

When I implemented the Build Previews in Background command of my Any Source plugin, I did a fair amount of reverse engineering to learn how photo:requestJpegThumbnail() works in practice. It appears to use LR's internal architecture for generating previews, which is tuned for building previews in background to avoid interfering with interactive use of LR.  I observed similar behavior as you did.

The plugin allows you to specify the number of concurrent requests to requestJpegThumbnail(). I found that there was no increase in performance for more than two concurrent requests, and CPU utilization rarely got higher than 35 - 50%, though the Library > Previews >Build Standard-Sized Previews can get close to 100%. Both the Build Standard-Sized Previews and Export use higher levels of concurrency, and Export uses the GPU by default, while preview building does not.

I also observed there is no way to cancel a request.