Quote:
Originally Posted by davidfor
I assume this means that I Kobo devices won't get the performance improvement you put in. I'll have a look at the thumbnails in the driver and see what is different.
|
Devices that cannot ask for different thumbnail/cover sizes on different connections will see the performance improvement. Devices that can ask for different thumbnail sizes might or might not produce correct results.
The assumption made by my code was that a thumbnail in a device book dict was made by gui2.device.cover_to_thumbnail. This was true for all the devices I have and have looked at, so my testing didn't find the (apparently) two devices that do something else.
Details: cover_to_thumbnail returns a 3-element tuple (width, height, image_bytes). One part of the optimization, the part that won't be done for Sony Tx and Kobo devices, was to check that the existing thumb is the size requested by the device. If it is not, then the thumbnail is regenerated and the book dict updated. If it is the same size and if nothing else in the mi structure has changed since the book's metadata was sent to the device (the other part of the optimization), then that book is left alone, saving a substantial amount of computation. In my testing the time savings was approximately 0.01 second per book on the device that did not need updating. YMMV depending on processor speed and memory available.
If the device can change the size of the thumbnail either "by itself" (e.g., a smart device) or by the user changing some preference, then if the tuple is not used it is possible that the thumbnail will not be updated upon connect. This is the incorrect result mentioned above. Another possibility: if the device depends on receiving a tuple but does not return a tuple, then the device might be surprised by receiving something unexpected, the value it put into the book dict.