GNOME Bugzilla – Bug 781736
Items with embedded orientation are slow to load
Last modified: 2017-11-27 17:53:52 UTC
Steps to reproduce: - add a new picture to $HOME/Images - go to Photos - click on the image to view it enlarged => it takes several seconds to display the image - now come back to the grid view - and click again on the image => now the image is displayed almost instantaneously I think it should not take so long to load the image. For example, it is approx. 3 times faster to load it in eog.
(In reply to Frédéric Parrenin from comment #0) > Steps to reproduce: > - add a new picture to $HOME/Images > - go to Photos > - click on the image to view it enlarged > => it takes several seconds to display the image > - now come back to the grid view > - and click again on the image > => now the image is displayed almost instantaneously That's because the decoded pixels are cached across memory and swap files. > I think it should not take so long to load the image. > For example, it is approx. 3 times faster to load it in eog. Now that sounds interesting. Eog and gnome-photos should take more or less the same time to read and decode the same image, unless: * the image was in a disk and/or filesystem cache when being loaded in eog, but not in the gnome-photos case * it is a RAW image that's masquerading as a TIFF or something in eog Would it be possible for you to attach a sample image that exhibits this behaviour?
Created attachment 350451 [details] .jpg file to reproduce the problem I attach a sample file to reproduce the problem. My configuration is a debian stretch distro on an old laptop (Dell Latitude E4300).
Thanks for the reproducer! I see that the image has an orientation tag. It might be that the slowness caused by the application of the orientation value. Those code paths are different in eog and gnome-photos. Maybe you can try an image that doesn't have an orientation tag. You can check with: $ tracker info /path/to/image | grep orientation
You are right: the images with a landscape orientation are loaded faster.
The slowness comes from GEGL's gegl:rotate-on-center that is used to rotate the item based on the embedded orientation value. While convenient to use because it can be plugged into the loading graph, I think gegl:rotate-on-center is overkill for this. Like all transform operations in GEGL, it uses a matrix to apply the rotation. We don't need to support rotations by arbitrary non-90 degree angles, so the use of a matrix doesn't buy us anything. My suggestion would be to use a fast path for angles that multiples of 90. See bug 592106 for an earlier attempt to do this; and GIMP's implementation in gimp/app/core/gimpdrawable-transform.c. Note that gegl:rotate-on-center currently adds an extra row and/or column of transparent pixels. It would be nice to somehow fix it. Fixing this might touch upon bug 789196
Created attachment 364295 [details] [review] base-item: Log the time taken to load a local file into a GeglBuffer
Created attachment 364296 [details] [review] gegl: Add photos_gegl_buffer_new_from_pixbuf
Created attachment 364297 [details] [review] gegl, thumbnailer: Don't use gegl:pixbuf
Created attachment 364298 [details] [review] gegl: Add photos_gegl_buffer_apply_orientation
Created attachment 364299 [details] [review] base-item, thumbnailer: Optimize application of embedded orientation
(In reply to Debarshi Ray from comment #5) > My suggestion would be to use a fast path for > angles that multiples of 90. See bug 592106 for an earlier attempt to do > this; and GIMP's implementation in gimp/app/core/gimpdrawable-transform.c. Avoiding gegl:rotate-on-center's samplers and matrix multiplication makes it 10 times faster to decode pixels off a file and apply the rotation, even in the worst case scenario where the angle of rotation is 180 degrees. This shows that the time taken to rotate the item was dwarfing the time taken to decode the image file format. > Note that gegl:rotate-on-center currently adds an extra row and/or column of > transparent pixels. It would be nice to somehow fix it. This is solved by not doing any sampling.
Some numbers. Before these patches: Attachment 350451 [details], which is a 12 megapixel image, took 3.216 seconds to load and orient from SSD storage. Landscape_3.jpg from https://github.com/recurser/exif-orientation-examples, which is a 2 megapixel image, took 0.588 seconds to load and orient from SSD storage. With these patches, those numbers drop to 0.385 and 0.065 seconds respectively.
Created attachment 364423 [details] [review] base-item: Log the time taken to load a local file into a GeglBuffer
Created attachment 364424 [details] [review] gegl: Add photos_gegl_buffer_new_from_pixbuf
Created attachment 364425 [details] [review] gegl, thumbnailer: Don't use gegl:pixbuf
Created attachment 364426 [details] [review] base-item: Sanity check the orientation values
Created attachment 364427 [details] [review] gegl: Add photos_gegl_buffer_apply_orientation
Created attachment 364428 [details] [review] base-item, thumbnailer: Optimize application of embedded orientation
Created attachment 364429 [details] [review] gegl: Remove unused function
Created attachment 364521 [details] [review] gegl: Update the list of mandatory operations