Sluggish performance when panning - cache invalidation bilat -> finalscale

Is there an existing issue for this?

• I checked and did not find my issue in the already reported ones

Describe the bug

While investigating #21426, I panned and zoomed a lot. Some of those ran quickly, others very slowly, with constant reprocessing of the pipe.
It turns out the differentiator is whether finalscale runs on the CPU (cache not used) vs GPU (cache used). (I'm still investigating why (on the same image, different runs) it used the CPU when the machine has 2 GPUs available; there were no OpenCL errors or anything similar logged).

Cache hits, usage, full pipe runs (check invalid and also Using -> weird, "Using 6784MB, limit=2007MB"):

$ grep -c 'cache HIT .*\[full HQ\]'  *_cache.txt
bad_cache.txt:0
good_cache.txt:60

$ grep 'cache HIT .*\[full HQ\]' good_cache.txt | grep -oE '\[full HQ\] +[a-z]+ +[0-9]+' | sort | uniq -c
     60 [full HQ]        bilat                  7300

$ grep 'cache report .*\[full HQ\]' bad_cache.txt  | tail -1
   137.1327 cache report                  [full HQ]                                     64 lines (important=8, used=53, invalid=17). Using 6784MB, limit=2007MB. Hits/run=0.00. Hits/test=0.000
$ grep 'cache report .*\[full HQ\]' good_cache.txt  | tail -1
    46.0890 cache report                  [full HQ]                                     64 lines (important=33, used=47, invalid=0). Using 2204MB, limit=2007MB. Hits/run=0.95. Hits/test=0.214

$ grep -cE 'process +(CPU|CL[0-9]) \[full HQ\] +rawprepare' *_cache.txt
bad_cache.txt:12
good_cache.txt:2

logs.zip

The root cause seems to be invalidation @jenshannoschwalm added in 9fbdc4b5.
I understand that Hanno's fix is needed. If I remove the invalidation, and place local contrast after AgX, then disable local contrast, I see messages like:

   209.8499 cache HIT                     [preview]        agx                    6000  IOP_CS_LAB 2.268 1.000 1.217, hash=3ae1c00c9e020619
   209.8499 pipe data: from cache         [preview]        agx                    6000       (0/0)  2714x1799 sc=1.000; 

AgX's output should be RGB, but local contrast converted it to Lab (its input space). In this case, there is no visible corruption (the buffer is marked as Lab, and gets converted to RGB by finalscale without loss in quality), but we probably shouldn't rely on that?

Instead of a module overwriting a previous module's output, how about avoiding overwriting the cached data with the converted one, and repeating the conversion instead?

• conversions aren't very frequent
• they are relatively fast - probably better to pay a guaranteed small conversion cost than invalidating the pipeline; an example of on-CPU conversion of a 160 MPx image:

   298.2384 [dt_ioppr_transform_image_colorspace] IOP_CS_LAB-->IOP_CS_RGB took 0.154 secs (1.464 CPU) [channelmixerrgb]
   302.7310 transform colorspace      CPU [full HQ]        bilat                  7000       (0/0) 16296x10856 sc=1.000; IOP_CS_RGB -> IOP_CS_LAB `linear Rec2020 RGB'
   303.2527 [dt_ioppr_transform_image_colorspace] IOP_CS_RGB-->IOP_CS_LAB took 0.522 secs (5.975 CPU) [bilat]
   323.9192 transform colorspace      CPU [full HQ]        finalscale             8500       (0/0) 16296x10856 sc=1.000; IOP_CS_LAB -> IOP_CS_RGB `linear Rec2020 RGB'
   324.0910 [dt_ioppr_transform_image_colorspace] IOP_CS_LAB-->IOP_CS_RGB took 0.171 secs (1.420 CPU) [finalscale]
  

Steps to reproduce

See the image from #21426 -- use HQ in the darkroom and pan around. Sometimes, but not always (I don't know the reason) we use the CPU.

Expected behavior

No response

Logfile | Screenshot | Screencast

No response

Commit

No response

Where did you obtain darktable from?

darktable.org / GitHub release

darktable version

5.7.0+18~g673e76aa90

What OS are you using?

Linux

What is the version of your OS?

Ubuntu 25.10

Describe your system

No response

Are you using OpenCL GPU in darktable?

None

If yes, what is the GPU card and driver?

No response

Please provide additional context if applicable. You can attach files too, but might need to rename to .txt or .zip

No response

Reproduce the issue in darkroom HQ mode with the image from #21426, comparing cache and processing logs during panning. Start by examining the invalidation introduced in commit 9fbdc4b5 and the color-space conversions around bilat and finalscale. Done means panning avoids unnecessary full-pipeline invalidation while cached data retains the correct color space.