Le lundi 7 juin 2021 à 21:03:45 UTC+2, Albrecht Schlosser a écrit :
test/doublebuffer runs "faster than ever seen" and there's no
noticeable difference between single and double buffer which is what
I expected. Manolo, there is no difference, right?
Yes. There's no such thing as a Wayland single window because it's not possible with Wayland to draw in the window. All drawing goes to a buffer,
and then this buffer is "committed" to Wayland. The two windows of test/doublebuffer follow exactly the same code.
test/glpuzzle does "funny things" (TM) if you let the game rotate
(drag the mouse and see). Borders disappear, sometime there's a
see-through effect.
Bill's hint below about the z buffer is probably the way to look to fix that. Help needed. I dont know GL.
Not all cursors appear as they should (test/cursor).
Yes, that happens with some Ubuntu themes but not all, and not with Debian, where all cursor shapes work.
Cursors are searched in a system folder and some shapes are absent for some Ubuntu themes. Who knows why?
Screen scaling (ctrl/+/-/0) doesn't seem to work yet. Maybe in GL
windows though (not sure). I've seen some weird effects.
Wayland was born when HighDPI existed, so it contains natively a way to handle HighDPI in the form of an integer scale whose value
grows with pixel density. FLTK apps follow this scaling without need for change nor ctrl/+/.
Go to Settings -> Display -> Scale and set it to 200% or 300 % on a large display, you'll see FLTK Wayland apps follow the change.
They're not adaptive while running yet, though.
test/resize-example* programs seem all to crash like this:
$ ./resize-example1
makeWindow:0x22499c0 wl_compositor_create_surface=0x2253bc0 scale=1
Segmentation fault (core dumped)
I'll look into that. I had not tried any of these test apps.
Oh, and one thing I did not expect:
./configure --enable-wayland --enable-cairo
doesn't work together. There are compilation errors (I don't
remember exactly, something about fl_gc and unsupported platform; I
could reproduce it but I'd need to reconfigure the build). I take it
this is just the platform tests in some header files, but anyway,
that's not important at all.
I had not tried that yet.
Manolo, well done! It's awesome to see that FLTK can work with
Wayland.
Conclusion: Using Cairo doesn't seem to be that slow in conjunction
with Wayland which uses (AFAICT) memory mapped buffers for
communication (rather than sockets or network connections like X11
does). How does "local X11" communicate? Anybody?
I have organized the code with 2 buffers of the same size for each window and subwindow:
- a drawing buffer where all drawing is made by Cairo. It's an array of bytes.
- a window buffer where the drawing buffer is copied after each drawing round. It has a Wayland-defined type (struct wl_buffer)
and contains memory shared with the compositor. When appropriate, that buffer gets 'committed' which means that Wayland
makes its content appear in the window.
Each window contains also two boolean state variables wl_buffer_ready and draw_buffer_needs_commit :
- draw_buffer_needs_commit becomes true after each drawing round and false after the drawing buffer has been copied to the window buffer;
- wl_buffer_ready becomes true when Wayland informs the program that the window buffer is ready to be loaded and committed,
and false when commit begins.
This way, only proper window content ever gets displayed, and Cairo can continue to draw when Wayland is not yet ready to display.
This synchronization is conspicuous with test/mandelbrot at maximized window size.
Manolo, would you like me to add CMake support? I'd like to help if
I can.
Yes I do. Many thanks.
But I believe we should first decide whether we want to include Wayland in the FLTK repo
and whether we do that as a new branch, or in the main branch, just like Android or Pico.
I would also appreciate feedback about use on a native Linux system (as opposed to a virtual machine).
