Some external reports of this:

1. https://productforums.google.com/forum/#!topic/chromebook-central/X5vyl82siDM
-- Reported Nov 2014, Samsung Chromebook 2 13
-- "Gallery is very slow when i open o folder witch contains many images (100 photos)."

2. https://www.reddit.com/r/chromeos/comments/46mksq/asus_flip_slow_picture_gallery/
-- Reported early 2016, Asus flip
-- "the machine stutters as you press the next button"

3. https://www.reddit.com/r/chromeos/comments/1j52ht/fast_image_viewer_for_chromeos/
-- Reported 2013
-- "image viewer built into the is really really slow."

4. http://www.digicamhelp.com/camera-logs/cool-stuff/is-chromebook-for-photographers/
-- reported ?
-- "using a Chromebook to to scroll through the batch of photos offline is a painful experience."

5. https://www.reddit.com/r/chromeos/comments/1i12sr/slow_when_going_through_photos/
-- reported 3 years ago, Acer chromebook
-- "scrolling through them it is incredibly slow and sometimes freezes up my computer"

I'm sure there's more, but you get the idea...

Given the large range of machines this reproduces on, and dating back to 3+ years, it seems like a fundamental problem with the Gallery app.

So just when it couldn't get any worse, now my HP Chromebook 13 (16GB) started developing a new symptom: when I navigate to a folder with 150+ 24MP jpg files from my camera, the machine just shuts down. 

Sometimes it happens when I try to open these files in Gallery, but sometimes it happens when I just go to the folder in the Files app.

Version 55.0.2883.103 (64-bit)
Platform 8872.73.0 (official build, stable channel)
ARC Version 3583806

Would it be possible for someone to file feedback (alt-shift-i) when this is happening?  From those logs we can check if it's application-level or system-level behavior.  Thanks.

(Also, I took the liberty of removing "painfully" and "stupidly" from the bug name---I think "incredibly" is sufficiently clear. :)

Thanks Luigi. I've submitted 4 or 5 feedback reports under this account with slow loading of previews in the gallery, hope it helps. I can try to provide more debugging info if needed. 

I find the issue is most easily reproduced with a fresh set of new images from an sdcard or other external source that are copied into a local folder for the first time. If I try to arbitrarily generate test data, e.g. by copy-pasting a single jpg file 256 times in the same folder, the issue still reproduces to some extent as seen in the dumps I just provided, but it seems not as severe (perhaps there's some caching of the image thumbs that's carried over in the copies?).

I took a look at those feedback reports.  (Replace XXXXXX with the user name below.)  I couldn't see anything unusual.

https://feedback.corp.google.com/product/208/neutron?lReportSearch=user:XXXXXX@google.com&lView=rl&lRSort=1&lROrder=2&lRFilter=1

Memory usage is contained, there is a lot of free RAM, so that's not the issue.  The list of GEM buffers is large but that could be normal.  I am not familiar with it.

Zel, do you have any suggestions for forwarding this?  I think we may have already run into it, if so I am surprised it hasn't been resolved yet.

> (1) Copy about 400 JPEG images from a 24MP DSLR SDCARD to a local folder.

We've recently removed expensive auto scan of image files on a SD card (instead, the scan will start after you click on the BACK UP button) [1]. I think the change will help.

There might be other problems around thumbnail generation etc. yamaguchi@, could you take a look? 


[1] https://bugs.chromium.org/p/chromium/issues/detail?id=668574

57.0.2978.0 / on Chromebook Pixel
55.0.2883.103 / 8872.73.0 on Chromebook Pixel 2
I tried with ~500 JPEG images (7900*5300, about 30 megabytes each).
I saw it sometimes takes about 5 seconds to navigate to a next image, but usually showed up in 2 or 3 seconds.
However, I could not see the ~20 seconds delay like reported.

The performance may be affected by these issues in the past:
1. [Fixed in M57] As noted in Comment #8, SD card scan in Files app may have affected the system performance.  crbug.com/668574 
2. [Fixed ~April 2016] It took long time (30--40 seconds, according to the bug description) before the first image appears. crbug.com/577345

Therefore it'd be helpful if we could see if the issue is as severe as before with the latest build.


There are still a couple of points which we can improve.

1. When the Gallery app opens, it starts to load metadata of every file in the folder in the background.
   - The duration of this task depends on the number of files in the folder. (On my Chromebook Pixel, it was around 0.2 seconds / image.) During this period, the UI will be slower.
2. A big image file (e.g. 24MP photo) takes several seconds to load from disk. (prefetch seems not working)

re: #9, I've noticed significant improvement in the last two weeks in-line with what you're describing, i.e. 2-5s delays, but no longer 20s+ :-) 

Any further performance improvements to this would be great too.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/9eb76629f83b6d9285876f88ce64e9fbe3ab373c

commit 9eb76629f83b6d9285876f88ce64e9fbe3ab373c
Author: yamaguchi <yamaguchi@chromium.org>
Date: Mon Jan 16 13:14:12 2017

Avoid UI unresponsiveness when switching between large images.

A new rendering of a big image can cause visible UI freeze even when the
image binary were already prefetched. This change forces to use thumbnail
image to begin slide-in animation quicker.

Downside of this change is that the thumbnail image will always be used
for the slide animation for larger images than the threshold, even when
flipping between 2 adjacent images back and forth. Before this change,
the full image could have been cached in the renderer by chance and might
have been working smoother on some platforms.

BUG= 656430 
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:closure_compilation

Review-Url: https://codereview.chromium.org/2629133002
Cr-Commit-Position: refs/heads/master@{#443880}

[modify] https://crrev.com/9eb76629f83b6d9285876f88ce64e9fbe3ab373c/ui/file_manager/gallery/js/gallery_item.js
[modify] https://crrev.com/9eb76629f83b6d9285876f88ce64e9fbe3ab373c/ui/file_manager/gallery/js/image_editor/image_view.js

I'm closing this issue based on #12 and #13.
One of the remaining issues, as well an idea to mitigate it, was filed as crbug.com/696423.