You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
So.. I had this beefy 93MB png image, and for the lulz I tried to compare IG's opening speed to the godawful W10 photo viewer.
To my dismay (at least after the first times, once the OS in all its wisdom decided to finally prefetch everything) that seemed ahead, which was counterintuitive to my usual experience.
After squeezing a bit further my eyes, I noticed that for a good half a second the fine detail in grilles and whatnot isn't really there. A low resolution version is first loaded, and only then the full quality appears.
Very much presumably (as side-way hinted here?) that's because they are first loading the thumbnails made beforehand by Windows explorer? In a very unscientific experiment after using the windows clean-up tool I seemed to corroborate this hypothesis.
Another possibility is just that IG has something else that could be further optimized, but v9 seems already so sleek otherwise.
It's no biggie then (particularly when IG already does everything in one second tops) but still I felt there could be room for improvement.
Additional context
*I guess* this may also help (or if not any interact) with some of the built-in cache related bugs that I noticed in the tracker.
The text was updated successfully, but these errors were encountered:
After reading this many times, I still don't understand what you want to suggest here 😅.
FYI:
ImageGlass 9 gets the thumbnails from Windows Explorer. If the format is not supported, it will use Magick.NET to create a thumbnail.
Some thumbnail extensions for Windows Explorer might affect the speed of loading as well. I've recently installed an extension to generate thumbnail for SVG format, it's much slower than using Magick.NET.
Another possibility is just that IG has something else that could be further optimized
ImageGlass v9.0 is the "new feature" cycle. v9.1 will be focusing on optimization.
I have already done a lot of optimizations in the latest code in develop branch. The app reduces ~150ms for cold start.
ImageGlass 9 gets the thumbnails from Windows Explorer.
I see. But gallery view aside, do you also try to show/use them for the "main image opening" step?
I was saying that I suspect windows' photo viewer can be faster, because at least showing the low-res preview before decoding of the real thing has been completed can be a tangible speed win for bigger files.
Is your feature request related to a problem? Please describe.
So.. I had this beefy 93MB png image, and for the lulz I tried to compare IG's opening speed to the godawful W10 photo viewer.
To my dismay (at least after the first times, once the OS in all its wisdom decided to finally prefetch everything) that seemed ahead, which was counterintuitive to my usual experience.
After squeezing a bit further my eyes, I noticed that for a good half a second the fine detail in grilles and whatnot isn't really there. A low resolution version is first loaded, and only then the full quality appears.
Very much presumably (as side-way hinted here?) that's because they are first loading the thumbnails made beforehand by Windows explorer? In a very unscientific experiment after using the windows clean-up tool I seemed to corroborate this hypothesis.
Describe the solution you'd like
Hook up anything of this probably?
https://learn.microsoft.com/en-us/windows/uwp/files/thumbnails
https://learn.microsoft.com/en-us/windows/win32/api/thumbcache/nn-thumbcache-ithumbnailcache
Describe alternatives you've considered
Another possibility is just that IG has something else that could be further optimized, but v9 seems already so sleek otherwise.
It's no biggie then (particularly when IG already does everything in one second tops) but still I felt there could be room for improvement.
Additional context
*I guess* this may also help (or if not any interact) with some of the built-in cache related bugs that I noticed in the tracker.
The text was updated successfully, but these errors were encountered: