The information about Mint 21.0 includes the following news for Xviewer:
"Continuously pressing the arrow keys results in a smooth slideshow where enough time is given for each picture to be visible."
This change was as the result of PR #164 (as a fix for issue #160). It restricted repeating key presses so that they occurred at around 250 milliseconds.
Unfortunately when submitting this PR I failed to realise just how long it can take Mint to load and then display images.
I was holding down the right-arrow key to scroll through a folder of images from a Nikon D3200. These were from about 7.5 to 15 MBytes (all 24 MPixels) - most of the time the images were shown correctly but there were glitches.
I then used a test tif image that is 9486 x 14703 pixels with a file size of 418.4 MBytes. The first time this image is displayed the load phase takes over 9 seconds, subsequent loads take approximately 5 seconds (I assume that the file has been cached)- there is clearly no way that the image can be displayed in the time allowed by the code from PR #164. A further delay occurs whilst the image is actually displayed.
Unfortunately I can't find any way with GTK to determine when the display of the image has been completed.
There are two phases to getting an image to appear on the screen. Firstly the loading phase and secondly the display phase. This PR uses the load job callback to determine the point at which the load phase has been completed. In this way any variation in time to load the image casued by processor speed, HD/SSD speed or file type is accommodated.
The new code then makes an allowance for the time in milliseconds taken for the display phase based on the number of pixels in the image. It adds this time to the current monotonic time in milliseconds and then adds a further 250 milliseconds to ensure that the image remains on display for at least 250 msec.
The time for which an image is displayed will, perforce, be extended by the time taken to load and display the following image - the bigger the following image the longer the current one will be displayed. This means that the phrase "smooth slideshow" above may not be entirely appropriate unless the images that are being displayed are all of a similar size.
I have tested the new code on relatively slow systems - a PC with an Intel i5-3330 CPU @ 3.00 GHz x 4 and Intel Xeon E3-1200 graphics with a HD and a laptop with an Intel Core i3-6100 CPU @ 2.30 GHz x 2 and Intel Skylake GT2 with an SSD. On both systems images are displayed for at least 250 msec.
To summarize - PR #164 improves the situation for smaller images but for medium to large images this new code is required.
The information about Mint 21.0 includes the following news for Xviewer:
"Continuously pressing the arrow keys results in a smooth slideshow where enough time is given for each picture to be visible."
This change was as the result of PR #164 (as a fix for issue #160). It restricted repeating key presses so that they occurred at around 250 milliseconds.
Unfortunately when submitting this PR I failed to realise just how long it can take Mint to load and then display images.
I was holding down the right-arrow key to scroll through a folder of images from a Nikon D3200. These were from about 7.5 to 15 MBytes (all 24 MPixels) - most of the time the images were shown correctly but there were glitches.
I then used a test tif image that is 9486 x 14703 pixels with a file size of 418.4 MBytes. The first time this image is displayed the load phase takes over 9 seconds, subsequent loads take approximately 5 seconds (I assume that the file has been cached)- there is clearly no way that the image can be displayed in the time allowed by the code from PR #164. A further delay occurs whilst the image is actually displayed.
Unfortunately I can't find any way with GTK to determine when the display of the image has been completed.
There are two phases to getting an image to appear on the screen. Firstly the loading phase and secondly the display phase. This PR uses the load job callback to determine the point at which the load phase has been completed. In this way any variation in time to load the image casued by processor speed, HD/SSD speed or file type is accommodated.
The new code then makes an allowance for the time in milliseconds taken for the display phase based on the number of pixels in the image. It adds this time to the current monotonic time in milliseconds and then adds a further 250 milliseconds to ensure that the image remains on display for at least 250 msec.
The time for which an image is displayed will, perforce, be extended by the time taken to load and display the following image - the bigger the following image the longer the current one will be displayed. This means that the phrase "smooth slideshow" above may not be entirely appropriate unless the images that are being displayed are all of a similar size.
I have tested the new code on relatively slow systems - a PC with an Intel i5-3330 CPU @ 3.00 GHz x 4 and Intel Xeon E3-1200 graphics with a HD and a laptop with an Intel Core i3-6100 CPU @ 2.30 GHz x 2 and Intel Skylake GT2 with an SSD. On both systems images are displayed for at least 250 msec.
To summarize - PR #164 improves the situation for smaller images but for medium to large images this new code is required.