summaryrefslogtreecommitdiff
path: root/documentation/src
diff options
context:
space:
mode:
authorManoloFLTK <41016272+ManoloFLTK@users.noreply.github.com>2023-10-03 08:12:13 +0200
committerManoloFLTK <41016272+ManoloFLTK@users.noreply.github.com>2023-10-03 08:12:13 +0200
commit74e63d907750cefd1154f99e62bcb0895b8a206b (patch)
treec46343df70790d9cf15338f87ab9cdeed16d4a8f /documentation/src
parent76b16d8cef24c4c548e21dad90cf2f8731ffceb9 (diff)
Wayland: document throttling redraws during interactive resizes
Diffstat (limited to 'documentation/src')
-rw-r--r--documentation/src/wayland.dox17
1 files changed, 15 insertions, 2 deletions
diff --git a/documentation/src/wayland.dox b/documentation/src/wayland.dox
index 066678ad7..84b93f0e7 100644
--- a/documentation/src/wayland.dox
+++ b/documentation/src/wayland.dox
@@ -618,14 +618,27 @@ has the effect that when the mapping operation eventually completes, Wayland run
\c draw_buffer_needs_commit member is true. The net result is that the screen
shows the most recent surface content.
+This synchronization mechanism is also used when performing an interactive window resize
+operation. During such operation, the compositor informs the client an interactive
+resize is being performed and sends window resize commands at high rate (~60 Hz) to the
+client via the socket. Libdecor turns on flag \c LIBDECOR_WINDOW_STATE_RESIZING
+to inform the client, and runs function \c handle_configure() for each received resize
+command. Before calling Fl_Group::resize() and later Fl_Window::draw(),
+\c handle_configure() tests whether \c window->buffer->cb is NULL. When it's not
+because a previous resize operation is being performed, the current resize command is
+skipped. At the end of the interactive resize, flag \c LIBDECOR_WINDOW_STATE_RESIZING
+is off and Wayland sends a final resize command which is not skipped. Overall, this
+ensures the client program resizes its window as frequently as it can without
+falling behind resize commands sent by the compositor.
+
<h3>Progressive window drawing</h3>
FLTK supports progressive drawing when an app calls function Fl_Window::make_current()
at any time and then calls the FLTK drawing API. This is made possible
in function \c Fl_Wayland_Window_Driver::make_current() with
\code
// to support progressive drawing
- if ( (!Fl_Wayland_Window_Driver::in_flush_) && window->buffer && (!window->buffer->cb) &&
- !wait_for_expose_value ) {
+ if ( (!Fl_Wayland_Window_Driver::in_flush_) && window->buffer && (!window->buffer->cb)
+ && window->buffer->draw_buffer_needs_commit && (!wait_for_expose_value) ) {
Fl_Wayland_Graphics_Driver::buffer_commit(window);
}
\endcode