Darktable: [lighttable - culling] got very slow {bisected}

Created on 31 Aug 2020  路  7Comments  路  Source: darktable-org/darktable

Describe the bug

suddenly scrolling in culling mode (newly imported pics) got extremely slow

To Reproduce

  1. Go to a folder with newly imported unedited photos around 900 pics
  2. Click on 'lighttable-culling mode'
  3. Scroll thru your collection
  4. See error

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):

  • darktable version : 3.3.0+507~gd25a47d7f
  • OS : Linux - kernel 5.7.15-gentoo
  • Distro : Gentoo Base System release 2.7
  • Processor : Intel(R) Core(TM) i9-9900K CPU @ 3.60GHz
  • Memory : 32 GB (4 x 8 GB) + 5GB Swap
  • Graphics card0 : GeForce GTX 1060 6GB
  • Graphics card1 : GeForce RTX 2070 SUPER
  • Graphics driver : nvidia-drivers-440.100-r2
  • OpenCL installed : Yes (opencl-headers-2020.03.13-r1)
  • OpenCL activated : Yes
  • Xorg : xorg-server-1.20.8-r1
  • Desktop : KDE 5
  • GTK+ : gtk+-3.24.22
  • gcc : x86_64-pc-linux-gnu-9.3.0
  • cflags : CFLAGS="-march=native-O2-mtune=native-pipe"
  • CMAKE_BUILD_TYPE : "Release"
wip UI

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 !

All 7 comments

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 :

  1. replace 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 image
  2. make some way bigger change by ensuring that we always know the final size of the image once it has been imported.

Of 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.

  • it does help but not as good as it was before the above mentioned commit.

@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:

  • I applied the code to current master
  • The speed I just subjectively compared.

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)

Was this page helpful?
0 / 5 - 0 ratings