From d9d474c59372a8b2b0829c400b5d0584129e3822 Mon Sep 17 00:00:00 2001 From: ManoloFLTK <41016272+ManoloFLTK@users.noreply.github.com> Date: Fri, 25 Aug 2023 16:19:12 +0200 Subject: Wayland.dox: add paragraph about rendering under Wayland --- documentation/src/wayland.dox | 10 +++++++++- 1 file changed, 9 insertions(+), 1 deletion(-) (limited to 'documentation/src') diff --git a/documentation/src/wayland.dox b/documentation/src/wayland.dox index 78233a2f2..f6d7fc8b5 100644 --- a/documentation/src/wayland.dox +++ b/documentation/src/wayland.dox @@ -42,7 +42,15 @@ of pointers to FLTK-defined callback functions associated to a Wayland-defined o Wayland calls these functions when defined events occur (more at \ref wayland-listeners below). -Wayland differs noticeably from X11 in that the position of a window in the display is +Wayland differs noticeably from X11 in that rendering is left to clients: Wayland provides +no drawing API. Instead, Wayland provides objects of type struct wl_buffer which +bundle a memory array of pixel values shared between the client and the compositor. +The client app is expected to draw to that memory buffer with whatever means it chooses, +and to instruct the compositor to map those pixels to the display when the drawing +is complete. The Wayland platform of FLTK draws with the Cairo library to \c Fl_Window's +and \c Fl_Image_Surface's, and with OpenGL to \c Fl_Gl_Window's. + +Wayland differs also from X11 in that the position of a window in the display is completely hidden to the client app. This prevents function \c Fl_Window::position() from having any effect on a top-level window. Wayland also prevents a client app from knowing whether a window is minimized: \c Fl_Window::show() has no effect on a minimized window. -- cgit v1.2.3