Be smarter about pre-caching images or don't cache altogether
Submitted by cli..@..ba.org
Link to original bug (#718616)
Description
---- Reported by clinton@yorba.org 2012-05-04 11:06:00 -0700 ----
Original Redmine bug id: 5202
Original URL: http://redmine.yorba.org/issues/5202
Searchable id: yorba-bug-5202
Original author: Clinton Rogers
Original description:
Several users on the mailing list have complained about severe performance regressions and/or crashes with very large images in direct-edit mode. As larger images become more common, it's only going to make the problems with the current scheme more evident.
Based on a conversation I had with Jim yesterday, the least painful way forward may be to remove the 'unmodified' cache mechanism and go back to the scaled decoding mechanism we had before (as I say this, I fully acknowledge that doing so will add a lot of complexity to coordinate-sensitive editing tools* that I originally wrote the current pipeline mechanism to remove or sidestep).
Tentatively marking for 0.13 (subject to triaging and priority change by the leads).
*We may be able to make this less painful and/or tidier by adding some kind of projection matrix mechanism that maps image space to screen space.
Related issues:
- related to shotwell - 4777: Very large images load in EoG but hang Shotwell (Open)
- related to shotwell - 4944: autoenhance on huge image exceeds available memory and cr... (Open)
- related to shotwell - 4937: [direct edit] moving to next/previous image is slow (Open)
---- Additional Comments From shotwell-maint@gnome.bugs 2013-05-16 14:44:00 -0700 ----
History
Comment 1
Updated by Lucas Beeler over 1 year ago
- Subject changed from Suggestion: revert the pipeline to the 'old' behaviour. to Be smarter about pre-caching images or don't cache altogether
We may be able to do the caching more intelligently. I have some ideas. Given the time we spent on coordinate transformations to get straightening to work in the 0.12 cycle I'd like to avoid opening up that rat's nest again if possible.
Comment 2
Updated by Laura Khalil over 1 year ago
I've noticed that moving through a library with photos that have a lot of pixelation, there is severe lag when trying to move from one photo to another. When I scroll through photos that have are less pixelated, I can right arrow through them just fine. Clint suggested I add a comment as it's probably related to this bug.
Comment 3
Updated by Clinton Rogers over 1 year ago
For those following the state of this bug:
http://redmine.yorba.org/projects/shotwell/repository/revisions/master/annotat e/src/Photo.vala#L3022
http://redmine.yorba.org/projects/shotwell/repository/revisions/master/annotat
e/src/Photo.vala#L3035
The first line tries to make a full-size copy of the image in memory so that a) we don't have to load it from disk again every time it's asked for and b) the pipeline (where all the rotate/straighten/crop/colour modification work happens) becomes very simple (coordinate-sensitive tools can work in image coordinates all the time without worrying about projecting to or from screen coordinates, and they can freely modify image data without ruining anything, since we have an unmodified copy cached at all times, etc).
This seemed like a good idea at the time (and preliminary testing with images below a certain size revealed that the application actually got faster); unfortunately, once we have an image file that expands to more than about 1 GB of image data, it starts to strain a bit under the weight of a 1 GB image and a copy of said image (recall that it keeps a 'pristine' one in memory). And of course, the larger the image, the more significant the memory usage becomes, to the point where an allocation could fail image is too large.
Comment 4
Updated by Adam Dingle about 1 year ago
- Priority changed from Normal to High
Comment 5
Updated by Adam Dingle about 1 year ago
-
Target version deleted (
<strike>
_0.13_</strike>
)
Comment 6
Updated by Jim Nelson 11 months ago
- Target version set to 0.14.0
Comment 7
Updated by Jim Nelson 11 months ago
- Category set to library-mode
Comment 8
Updated by Jim Nelson 11 months ago
- Category changed from library-mode to pipeline
- Target version changed from 0.14.0 to 0.15.0
We'll try and get to this in 0.15.
Comment 9
Updated by Jim Nelson 11 months ago
- Tracker changed from Task to Bug
Comment 10
Updated by Jim Nelson 8 months ago
- Target version changed from 0.15.0 to 0.16.0
Comment 11
Updated by Jim Nelson 6 months ago
-
Target version deleted (
<strike>
_0.16.0_</strike>
)
--- Bug imported by chaz@yorba.org 2013-11-25 21:57 UTC ---
This bug was previously known as bug 5202 at http://redmine.yorba.org/show_bug.cgi?id=5202
Unknown version " in product shotwell. Setting version to "!unspecified". Unknown milestone "unknown in product shotwell. Setting to default milestone for this product, "---". Setting qa contact to the default for this product. This bug either had no qa contact or an invalid one. Resolution set on an open status. Dropping resolution
Resolution: RESOLVED FIXED