Skip to content

Improve obsolete pipecache handling - #21572

Closed
jenshannoschwalm wants to merge 2 commits into
darktable-org:masterfrom
jenshannoschwalm:improved_cache_obsolete
Closed

Improve obsolete pipecache handling#21572
jenshannoschwalm wants to merge 2 commits into
darktable-org:masterfrom
jenshannoschwalm:improved_cache_obsolete

Conversation

@jenshannoschwalm

Copy link
Copy Markdown
Collaborator

Currently we use gboolean cache_obsolete to enforce a complete invalidation of the pipe's cache before the next pixelpipe run.

We had that for years, it was introduced and required as a workaround while the hash calculation for piece and cachelines were not "complete". Using this flag leads to bad UI response as a reprocessed pipe will never get a cacheline hit after obsolete.

Instead of using a gboolean we now have uint32_t cache_obsolete_order, defaulting to INT_MAX.
If set to anything below, only the cachelines with iop_order >= cache_obsolete_order will be invalidated before the next pixelpipe run.
This allows a fine control for what cachelines shouldn't be used for a cache-hit thus we have a clearly faster response in many situations triggered by the user.

Two helpers were modified, both take the iop_order as an extra argument, note that using an iop_order of 0 will do a complete cache flush (as we had with the old gboolean).
void dt_dev_reprocess_center(dt_develop_t *dev, const int32_t iop_order)
void dt_dev_reprocess_preview(dt_develop_t *dev, const int32_t iop_order)

Currently we use `gboolean cache_obsolete` to enforce a complete invalidation of the pipe's cache
before the **next** pixelpipe run.
We had that for years, it was introduced and required as a workaround while the hash calculation
for piece and cachelines were not "complete".
Using the flag leads to bad UI response as a reprocessed pipe will never get a cacheline hit.

Instead of using a `gboolean` we now have `uint32_t cache_obsolete_order`, defaulting to INT_MAX.
If set to anything below, the cachelines with `iop_order >= cache_obsolete_order` will be invalidated
before the next pixelpipe run.
This allows a finer control for what cachelines shouldn't be used for a cache-hit thus we have
a clearly faster response in many situations triggered by the user.

Two helpers were modified, both take the iop_order as an extra argument, note that using an
iop_order of `0` will do a complete cache flush (as we had with the old gboolean).
`void dt_dev_reprocess_center(dt_develop_t *dev, const int32_t iop_order)`
`void dt_dev_reprocess_preview(dt_develop_t *dev, const int32_t iop_order)`
@jenshannoschwalm jenshannoschwalm added this to the 5.8 milestone Jul 19, 2026
@jenshannoschwalm jenshannoschwalm added feature: redesign current features to rewrite scope: UI user interface and interactions scope: performance doing everything the same but faster release notes: pending labels Jul 19, 2026
1. Request for details mask
2. Selecting a history item in history lib

both require cacheline invalidations, simplyfied code in both cases.
@jenshannoschwalm
jenshannoschwalm deleted the improved_cache_obsolete branch July 20, 2026 10:59
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

feature: redesign current features to rewrite release notes: pending scope: performance doing everything the same but faster scope: UI user interface and interactions

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant