darkroom: refresh image info and stabilize panel layout

[Arecsu]

Fixes #20018

Refresh the image information line after asynchronous image switches, and redraw the darkroom bottom toolboxes on image changes and UI-pipe completion so their custom-drawn buttons do not remain stale until hover.

Follow-up: queue redraws for all footer toolbar descendants, not only the toolbar containers. GTK3 does not reliably invalidate the custom-drawn child buttons when the footer is repainted, which could leave the bottom controls and image info line blank until hover or image processing completed. The child traversal uses GTK3/GTK4-appropriate APIs.

The footer redraw is now deferred and coalesced until image-change signal handlers and pending layout updates have completed, avoiding repainting against intermediate footer allocations and reducing visible flicker when switching images, especially while zoomed in.

Finally, center redraws are deferred until UI-pipe completion. Redrawing the center from the image-change callback could recalculate viewport bounds and scrollbars while the new pixelpipe dimensions were still intermediate, causing transient side-panel resizing and scrollbar jumps during image switches.

The duplicate manager now keeps a fixed action area for each row. When an image has no duplicate versions, the delete action is unavailable, but its slot remains reserved so the duplicate and virgin-duplicate buttons do not move or cause unwanted sidebar width changes when switching images.

[Arecsu]

@anoderay please if you can test this one out, would be neat! as you were the one who was normally experiencing these bugs. Addresses both issues you've described at #20018

[anoderay]

Thanks @Arecsu !

Partially fixed:

Bildschirmaufnahme_20260822_092126.webm

The infoline still doesn't always load. The buttons appear to vanish and then appear back, which feels choppy.

[Copilot]

Pull request overview

This PR addresses darkroom UI staleness during/after asynchronous image switches by forcing timely redraws of the image info line and the bottom toolboxes, aligning with the reported symptom in #20018 (info line not updating when zoomed in and switching images quickly).

Changes:

• Redraw darkroom bottom toolboxes on image changes and UI-pipe completion to prevent custom-drawn buttons from remaining visually stale until hover.
• Add an imgid-based consistency check in the image infos lib so UI-pipe completion can refresh the info line if the async image-changed callback hasn’t updated it yet.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated no comments.

File	Description
src/views/darkroom.c	Adds a unified redraw callback for center + bottom toolboxes on image change / UI-pipe finish.
src/libs/tools/image_infos.c	Tracks last-updated imgid and refreshes the info label on UI-pipe finish if needed.

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[Arecsu]

@anoderay thanks for checking and the video as well, very useful. Check it again as I've made a new commit that should put a nail in the coffin to this problem once and for all 😊

[anoderay]

Re-Tested:

Bildschirmaufnahme_20260822_182011.webm

The Infoline seems to always load. The fact that it sometimes flickers out and in when switching images still feels slightly janky but to me. It is mostly the case when switching while zoomed in but also sometimes happens when zoomed to "fit". Curiously it seems to never happen with HQP enabled. It doesn't seem to happen while switching between duplicates of the same Image.

I guess the current state is fine; no visible re-drawing of the infoline/buttons would make switching images feel more solid though IMHO. I hope I don't come across ungrateful; just trying to describe what I am experiencing while testing.

Thanks for putting in the time :-) .

[Arecsu]

@anoderay check if this last change fixes the jankiness of it!

[anoderay]

It is rock-solid now :-) !

Bildschirmaufnahme_20260822_194542.webm

Thanks 🥳 !

And to ensure you don't get bored 2 new issues (want me to post an issue for those?) when compiling from this PRs branch:

1.) Left panel resizes depending on orientation/aspect ratio of the images. Note that when switching to a portrait-oriented shot the left panel gets slimmer (not present in 5.6 or master)
2.) The log-button doesn't open the logging window (works in 5.6 but also broken in master)

[anoderay]

Ah I didn't show the zoomed in version. If you want to iron out the very last grain of jank: When switching images zoomed in the scroll bars jump around for a millisecond (same in 5.6 but feels less pronounced). Would be fine to leave as is though as those scroll bars are disabled by default anyway ;-) .

[Arecsu]

Nice Yannic! 🎉 Thank you for reporting back! Check this last change I've pushed which should get rid of the resizing and scroll bar jump as well. The log button, that's something we've been patching for many other buttons as well and I'll make it into a new PR. The only thing I will ask is if, once I do the PR, you could test that one out and see if the logs spawns the logging window.

[anoderay]

did not fix the slight jumpyness. Not sure if it is worth fixing.

Bildschirmaufnahme_20260822_205643.webm

[Arecsu]

Did it fix the sidebar width changes? These scrollbar jumpiness is clearly something that goes far in deep and I get the feeling fixing this will be hacky, and not compatible at all with gtk4. And at this point, a full move to gtk4 could potentially fix this in a cleaner way already. So yeah, I will leave it for GTK4. The important one is the sidebar though

[anoderay]

re-built and tested: No, Left panel still changes. but upon further inspection it doesn't just change with aspect ratio, sometimes also between images that have the same aspect ratio - and sometimes doesn't change with different aspect ratios. Did some testing cropping images but cannot precisely say what triggers the behaviour :-( .

Bildschirmaufnahme_20260822_213331.webm

[Arecsu]

Hmmm will debug this further next week, thank you for testing! 🤗

[anoderay]

👍 can I help with some logs?

[Arecsu]

@anoderay actually yes, as it is hard to trigger this myself. I've turned this into a draft PR and filled the important code paths with logs that should be fairly important in this matter.

Please compile a build with this PR and its last changes, then run it with "darktable -d dev" and provide everything you can. If there is a way you can segment the logs with the actions you've done at the specific points that would be amazing (not needed I think but just to be sure)

[anoderay]

I don't exactly know what you meant by segmenting but I recorded the screen while the following log was captured:
log_20260823_083417.log

Bildschirmaufnahme_20260823_083436.webm

[Arecsu]

Yes that helps clearly. Nice! If you can trigger one more test like the logs and video you did, please do!

I've added a workaround to keep the side panel width. In short: there is something that happens when you change between images that reports a higher than configured minimal sidebar width. Something like 233px. It happens "randomly":

  24.6482 callback-image-changed imgid=13
  24.6713 sidepanel-measure panel=left minimum=233 configured=221
  24.6771 sidepanel-measure ... allocated=233

As you can see, 221px is the actual size you configured previously. 233px > 221px so it picks that new minimum.
Then, the minimum reverts back to where it was previously, which is 203px.

  30.2705 callback-image-changed imgid=17
  30.2895 sidepanel-measure panel=left minimum=203 configured=221
  30.2940 sidepanel-measure ... allocated=221

The configured changes with your interaction, but the sidebar settles on the minimum value if it's higher than the configured.

With the new logs (use darktable -d dev) we may see where it actually originates to track down this change even further and make the fix more robust. You should not see any sidebar width changing now because of the new guard I added, but as mentioned, if we get this one log we could potentially patch something deeper and, who knows, save someone's life in the future or an unreported bug right now

[anoderay]

Bildschirmaufnahme_20260823_153832.webm

log_20260823_153816.log

FYI: Video stops before the log does...

It's the fault of the duplicate manager I think. In the video you can see that there is still some jumpyness in the text of the modules - I think when changing between the same Images as before. I did some trials and when the duplicate Manager is not enabled in the left panel this phenomenon goes away. See:

Bildschirmaufnahme_20260823_154326.webm

log_20260823_154306.log

It only seems to happen when the left panel is too small for the duplicate manager to display all of it's three buttons, which are only present when duplicates exist - which also explains why it only happens with some photos; I was at first mislead thinking it was about aspect ratio, that was just a coincidence.

also the redraw of the Duplicate manager is slightly jumpy when switching images.

[Arecsu]

oh that awesome!!!!!!! Yes, indeed, it's because of the duplicate manager. The difference is that when there is a picture that has duplicates, each duplicate inside the module has a new button, the "delete duplicate", whereas an image without duplicates does not have that button. That one makes the sidebar bigger or smaller :). So, to confirm, when you hide the duplicate manager module, no width changes happen at all right?

[anoderay]

So, to confirm, when you hide the duplicate manager module, no width changes happen at all right?

yes! See the second video in the post above.

[Arecsu]

That is something I've learned in all my years as a web dev: you don't completely remove buttons from a layout. You must "visually hide them" and disable its interactions, so they are still being calculated in the layout properly, to avoid cases like this. I'm trying to do that by the way, BUT there are ghosts and demons haunting there with a janky flash of that button appearing and hiding with each image change. In hopes to keep things elegant and cleaner I'll try another way of getting around that behavior properly :)

[Arecsu]

@anoderay should be ready now, test it. Logs were removed so you might test just normally and report back. If everything goes right, this PR is already set to be merged

[anoderay]

Yep; left panel stable now between images with and without duplicates :-) .