From 74e63d907750cefd1154f99e62bcb0895b8a206b Mon Sep 17 00:00:00 2001 From: ManoloFLTK <41016272+ManoloFLTK@users.noreply.github.com> Date: Tue, 3 Oct 2023 08:12:13 +0200 Subject: Wayland: document throttling redraws during interactive resizes --- documentation/src/wayland.dox | 17 +++++++++++++++-- 1 file changed, 15 insertions(+), 2 deletions(-) (limited to 'documentation/src') 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. +