Skip to content

darkroom: fix viewport not refreshing on Win32 GDK backend#21128

Open
jsmucr wants to merge 1 commit into
darktable-org:masterfrom
jsmucr:fix/issue-20831-darkroom-redraw-win32
Open

darkroom: fix viewport not refreshing on Win32 GDK backend#21128
jsmucr wants to merge 1 commit into
darktable-org:masterfrom
jsmucr:fix/issue-20831-darkroom-redraw-win32

Conversation

@jsmucr

@jsmucr jsmucr commented May 25, 2026

Copy link
Copy Markdown
Contributor

On Windows (GTK 3.24.52, MSYS2/UCRT64), the darkroom viewport failed to redraw after zoom, pan, or overlay changes. The widget's draw handler was called but the content never appeared on screen until an external trigger (e.g. window move) forced a full surface recreation.

Root cause: commit 76ff82f ("fix regression in darkroom switching between images") introduced a cairo_surface_reference() to cairo_get_target(cri) — GTK's internal drawing surface — to cache the rendered image for smooth transitions when loading_screen is OFF. On the Win32 GDK backend this prevents GTK from properly invalidating the widget, causing gtk_widget_queue_draw() to silently fail.

The original double buffering via a standalone gui->surface was removed in 8976447 ("remove unnecessary double buffering"). Commit 76ff82f re-introduced surface caching but took a shortcut by referencing GTK's target rather than maintaining a proper standalone surface.

Fix by copying the rendered content into a standalone cairo_image_surface instead of referencing GTK's internal target. Also:

  • Add pipe->changed to _full_request() so the pipe is resubmitted when zoom/pan changes are pending, regardless of pipe status.
  • Add !pipe->loading to expose_full condition to prevent displaying stale backbuf data while a new image is being loaded.
  • Clear backbuf, output_imgid, and cached surface in leave() so re-entering darkroom starts with a clean state.
  • Paint darkroom background when no cached surface is available (first entry from lighttable with loading_screen OFF).

Note: GTK overlay widgets (e.g. toast messages) may still composite against a stale backing store during the loading phase. This is a pre-existing GTK Win32 compositor limitation and is not addressed here.

Fixes #20831

@jsmucr jsmucr force-pushed the fix/issue-20831-darkroom-redraw-win32 branch 3 times, most recently from 703b4c8 to d2aeb30 Compare June 1, 2026 06:43
@jenshannoschwalm

Copy link
Copy Markdown
Collaborator

I don't have access to windows systems but from your description i think we might have fixed this in master

@jsmucr

jsmucr commented Jun 2, 2026

Copy link
Copy Markdown
Contributor Author

I'll check.

@jsmucr

jsmucr commented Jun 2, 2026

Copy link
Copy Markdown
Contributor Author

@jenshannoschwalm No, still not fixed, I'm afraid.

On Windows (GTK 3.24.52, MSYS2/UCRT64), the darkroom viewport failed
to redraw after zoom, pan, or overlay changes. The widget's draw handler
was called but the content never appeared on screen until an external
trigger (e.g. window move) forced a full surface recreation.

Root cause: commit 76ff82f ("fix regression in darkroom switching
between images") introduced a cairo_surface_reference() to
cairo_get_target(cri) — GTK's internal drawing surface — to cache the
rendered image for smooth transitions when loading_screen is OFF. On the
Win32 GDK backend this prevents GTK from properly invalidating the
widget, causing gtk_widget_queue_draw() to silently fail.

The original double buffering via a standalone gui->surface was removed
in 8976447 ("remove unnecessary double buffering"). Commit 76ff82f
re-introduced surface caching but took a shortcut by referencing GTK's
target rather than maintaining a proper standalone surface.

Fix by copying the rendered content into a standalone cairo_image_surface
instead of referencing GTK's internal target. Also:

- Add pipe->changed to _full_request() so the pipe is resubmitted when
  zoom/pan changes are pending, regardless of pipe status.
- Add !pipe->loading to expose_full condition to prevent displaying stale
  backbuf data while a new image is being loaded.
- Clear backbuf, output_imgid, and cached surface in leave() so
  re-entering darkroom starts with a clean state.
- Paint darkroom background when no cached surface is available (first
  entry from lighttable with loading_screen OFF).

Note: GTK overlay widgets (e.g. toast messages) may still composite
against a stale backing store during the loading phase. This is a
pre-existing GTK Win32 compositor limitation and is not addressed here.

Fixes darktable-org#20831
@jsmucr jsmucr force-pushed the fix/issue-20831-darkroom-redraw-win32 branch from d2aeb30 to 9e9b2ee Compare June 8, 2026 05:12
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Image not refreshed on change (Win32 GTK)

2 participants