darkroom: fix viewport not refreshing on Win32 GDK backend#21128
Open
jsmucr wants to merge 1 commit into
Open
Conversation
703b4c8 to
d2aeb30
Compare
Collaborator
|
I don't have access to windows systems but from your description i think we might have fixed this in master |
Contributor
Author
|
I'll check. |
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
d2aeb30 to
9e9b2ee
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
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:
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