Describe the bug
suddenly scrolling in culling mode (newly imported pics) got extremely slow
To Reproduce
Expected behavior
snappy fast as it was
bisect
5284304003d2865255bc3f781c1036601e30e90e is the first bad commit
commit 5284304003d2865255bc3f781c1036601e30e90e
Author: AlicVB dev@lnaa.fr
Date: Sun Aug 23 15:24:19 2020 +0200
culling : retain zoom values for next-prev images
src/dtgtk/culling.c | 26 ++++++++++++++++++++++++++
src/dtgtk/thumbnail.c | 1 +
2 files changed, 27 insertions(+)
@AlicVB may I ping you here and hope, you will not say "cannot reproduce..." :)
Platform (please complete the following information):
Thanks a lot for the bisecting !
I know exactly what happen :
The above commit is here so we keep zoom level when scrolling through images. But before applying the previous zoom level to the new image, we need to sanitize it, and so to call dt_thumbnail_get_zoom100 which in turn call dt_image_get_final_size and this last one is really slow...
I see 2 solution here :
src/dtgtk/thumbnail.c:400 by if (thumb->zoom>1.0f) thumb->zoom = MIN(thumb->zoom, dt_thumbnail_get_zoom100(thumb)); This will only call the slow fct if we have zoomed so reducing the "slowiness" to the scrolling through zoomed imageOf course 2. is better (and will solve #6152), but I'm not sure it's feasible... @TurboGit : I wonder if there's not something like that for aspect ratio already... Maybe you remember ?
@AxelG-DE : are you able to test 1. and report if that solve the problem for you ? Thanks
@AlicVB
I tested (1) as you asked.
@AxelG-DE : guess why... I can't reproduce :) (with the code change I've proposed)
And to honest, I've no idea what could cause the slowiness in the rest of the code in commit https://github.com/darktable-org/darktable/commit/5284304003d2865255bc3f781c1036601e30e90e
@AlicVB
I am afraid when I reply your questions honestly, you will be disappointed :smile:
Without your snippet, the speed differences was huge. With your snipped (solution 1), it is already very useful again, so I can live with it, just I felt, it was even snappier before. Keep in mind, I have a tick-free mouse-wheel :)
Great, thanks !
so I think we have a solution for one part of the bug already. That's great !
And reading your answer (not disappointed at all ;)), I think that the remaining part occurs in a change somewhere between https://github.com/darktable-org/darktable/commit/5284304003d2865255bc3f781c1036601e30e90e and master.
I'll try to do some magic git to see what has changed and try to find the culprit there.
Anyway, if I don't find the second problem quickly, I'll fix the first one !
So, I've apparently seen nothing that would produce any real slowiness inside the code :(
Hence I've just pushed the fix for the first part...
I C
thanks...
(have another odity, but didn't come back ever since, two pics from Olympus (4:3) cropped 3:2, did appear in different size when culling was set to zoom 2)
Most helpful comment
Great, thanks !
so I think we have a solution for one part of the bug already. That's great !
And reading your answer (not disappointed at all ;)), I think that the remaining part occurs in a change somewhere between https://github.com/darktable-org/darktable/commit/5284304003d2865255bc3f781c1036601e30e90e and master.
I'll try to do some magic git to see what has changed and try to find the culprit there.
Anyway, if I don't find the second problem quickly, I'll fix the first one !