Wayland test results

35 views
Skip to first unread message

Albrecht Schlosser

unread,
Oct 18, 2021, 8:42:15 AM10/18/21
to fltk.coredev
Some observations with the latest Wayland commit 06f6f01cc351859 (all
tests on Linux Mint with Weston):

Drawing lines, points, circles, curves etc. is excellent, rotated text
is superb! The gleam scheme looks very good (with some really minor
artifacts when scaled). Tested with unittests and some more test programs.

glpuzzle: very slow spinning when you drag the mouse on the board.
Hitting 'space' or 'n' key which should stop spinning reacts delayed
rather than immediately. There seems to be a very long "pipeline" of
events to be serviced before the app reacts. Even the window close
button seems to react delayed while the puzzle is spinning.

threads: sluggish like glpuzzle when trying to stop the demo (delay ~5
seconds in my tests). This may be caused by the WM or Weston though, I
don't know.

sudoku: this app should change its window title but this doesn't happen
in my test environment. To test you can use the "Difficulty" menu.

mandelbrot: dragging the mouse leaves a trace of rectangles. ISTR that
this is a known issue, but anyway.

tile: the horizontal drag cursor is fine (FL_CURSOR_WE, the vertical
drag cursor (FL_CURSOR_NS) doesn't appear. Dragging an intersection of
more than two sections displays a somewhat uncommon "hand" cursor (a
normal cursor with a small white square or something similar). This is
obviously FL_CURSOR_MOVE (as displayed by the cursor demo).

Note: the "cursor" demo displays FL_CURSOR_HAND correctly (a "hand") but
FL_CURSOR_NS is shown as the "normal" cursor.

message and ask: the popup windows (fl_message et al.) seem to pop up at
arbitrary locations. Particularly the "hotspot" setting doesn't seem to
work (at least not always). I couldn't test this further though.

Other observations:

It's sometimes difficult to drag a window border because the cursor
doesn't change when you hover over the border. This is particularly an
issue on the left and top sides and corners. It works *much* better at
the bottom and right sides and the bottom right corner. I got the
impression that you can drag the border even if the cursor doesn't
indicate it. If you do so the cursor changes as soon as you click the
mouse near the border or corner.

I ran out of time, hence I had to stop my tests here. Summary: many,
many things (which I didn't mention explicitly) work flawlessly but I
couldn't test every demo program. The glitches mentioned above are no
real show stoppers but in parts inconvenient.

Altogether: it's awesome! Great work! Thank you very much, Manolo.

Manolo

unread,
Oct 19, 2021, 6:26:51 AM10/19/21
to fltk.coredev
Le lundi 18 octobre 2021 à 14:42:15 UTC+2, Albrecht Schlosser a écrit :
Some observations with the latest Wayland commit 06f6f01cc351859 (all
tests on Linux Mint with Weston):
Thanks for testing.

Drawing lines, points, circles, curves etc. is excellent, rotated text
is superb! The gleam scheme looks very good (with some really minor
artifacts when scaled). Tested with unittests and some more test programs.
This is 100% pure cairo+pango. Scaling is done by calling cairo_scale().

glpuzzle: very slow spinning when you drag the mouse on the board.
Hitting 'space' or 'n' key which should stop spinning reacts delayed
rather than immediately. There seems to be a very long "pipeline" of
events to be serviced before the app reacts. Even the window close
button seems to react delayed while the puzzle is spinning.
There's a special handling for top-level GL windows (as opposed  to GL
subwindows) that may explain that.

threads: sluggish like glpuzzle when trying to stop the demo (delay ~5
seconds in my tests). This may be caused by the WM or Weston though, I
don't know.
Or by the virtual machine handling. This would need testing on a real Linux box.

sudoku: this app should change its window title but this doesn't happen
in my test environment. To test you can use the "Difficulty" menu.
That's most probably a Weston bug, because the title changes correctly with
Mutter and KDE. The code calls all functions to redraw the title, but it doesn't
show on the display. The changed title is visible as soon as the titlebar gets redrawn
(e.g. horizontal resize).

mandelbrot: dragging the mouse leaves a trace of rectangles. ISTR that
this is a known issue, but anyway.
Yes, it's a known issue. I believe it's done by cairo slightly leaking out of its clip box
when drawing an image, and I'm afraid it may be difficult to fix. I believe the same
cause also explains why, after zooming in or out the image, faint traces of the previous
scene remain visible in the new scene.

tile: the horizontal drag cursor is fine (FL_CURSOR_WE, the vertical
drag cursor (FL_CURSOR_NS) doesn't appear. Dragging an intersection of
more than two sections displays a somewhat uncommon "hand" cursor (a
normal cursor with a small white square or something similar). This is
obviously FL_CURSOR_MOVE (as displayed by the cursor demo).
None of that happens with Mutter or KDE. This looks like another Weston bug
that doesn't redraw the cursor when it should.

Note: the "cursor" demo displays FL_CURSOR_HAND correctly (a "hand") but
FL_CURSOR_NS is shown as the "normal" cursor.
In my hands (Debian or Ubuntu in a virtual machine), the cursor demo doesn't ever
change the cursor shape with weston, although all required shapes are found by the adequate
Wayland function (wl_cursor_theme_get_cursor). The same cursor executable works
flawlessly with Mutter and KDE. For me, that's a weston bug.


message and ask: the popup windows (fl_message et al.) seem to pop up at
arbitrary locations. Particularly the "hotspot" setting doesn't seem to
work (at least not always). I couldn't test this further though.
The Wayland FLTK implementation doesn't attempt to control the location of toplevel
windows on the display because Wayland offers no way to do it. That's a feature of Wayland.
It's possible, though, to locate a window relatively to another one. That's used for menu and
tooltip windows. That's also used, in the Wayland platform only, for the transient yellow
window that shows the new GUI scale factor which is centered relatively to the front
toplevel window. I see no way to position a window relatively to the cursor with Wayland.

Other observations:

It's sometimes difficult to drag a window border because the cursor
doesn't change when you hover over the border. This is particularly an
issue on the left and top sides and corners. It works *much* better at
the bottom and right sides and the bottom right corner. I got the
impression that you can drag the border even if the cursor doesn't
indicate it. If you do so the cursor changes as soon as you click the
mouse near the border or corner.
None of that is under FLTK control. It's all done by the wayland compositor,
Weston in your case. In my hands it's as difficult to resize an FLTK window
as it is for a non-FLTK window such as gedit or gnome-terminal. Again, other
compositors (Mutter, KDE) handle much better these things.

I ran out of time, hence I had to stop my tests here. Summary: many,
many things (which I didn't mention explicitly) work flawlessly but I
couldn't test every demo program. The glitches mentioned above are no
real show stoppers but in parts inconvenient.

Altogether: it's awesome! Great work! Thank you very much, Manolo.

In general terms, my feeling now is that Weston is not really usable (yet?) in a desktop
environment, whereas gnome's Mutter and KDE support much better all window
operations (resize, redraw, hide, show, rename, cursor changes, etc…) expected in a desktop setting. It's also
what I read in weston's presentation in its own source repository :
"Weston is the reference implementation of a Wayland compositor, as well as a useful environment in and of itself.

Out of the box, Weston provides a very basic desktop, or a full-featured environment for non-desktop uses…

If you are after a more mainline desktop experience, the GNOME and KDE projects provide full-featured desktop environments built on the Wayland protocol."

I also read that the gnome desktop can be installed under Linux Mint.

I have communicated with Jonas Ådahl, libdecor's lead author. He wrote that the traces left on the display when a window framed by libdecor is minimized under weston is a weston bug. Since he's also a weston developer, he committed a fix for that in the weston code repository (https://gitlab.freedesktop.org/wayland/weston/-/commit/56958aa6e9c7c20909c99e978514d99a3c943ed8). That will be included in the next weston release and later will make its way into linux distributions. Meanwhile, FLTK hides the window frame while a window is minimized under weston and restores it when that window gets unminimized.


Albrecht Schlosser

unread,
Oct 19, 2021, 6:55:47 AM10/19/21
to fltkc...@googlegroups.com
On 10/19/21 12:26 PM Manolo wrote:
Le lundi 18 octobre 2021 à 14:42:15 UTC+2, Albrecht Schlosser a écrit :
Some observations with the latest Wayland commit 06f6f01cc351859 (all
tests on Linux Mint with Weston):
Thanks for testing.

Thanks for your comments. I'm replying only to some selected ones.

glpuzzle: very slow spinning when you drag the mouse on the board.
...
There's a special handling for top-level GL windows (as opposed  to GL
subwindows) that may explain that.

Is this a general FLTK/Wayland issue, and do you think this can be "fixed"?


threads: sluggish like glpuzzle when trying to stop the demo (delay ~5
seconds in my tests). This may be caused by the WM or Weston though, I
don't know.
Or by the virtual machine handling. This would need testing on a real Linux box.

The tests were executed on a real Linux Mint 20 box with `weston` executed as an application which opens its own window.

FYI: this is a dual boot Linux/Win10 system so I can still do native tests on Windows. I also have some VM's on this system, so I can test:

- Linux Mint 20 native (I'll try to use the Gnome/Wayland desktop later)
- Windows 10 native

In Virtualbox VM's on Linux Mint:
- Windows 10
- Ubuntu with Ubuntu or Gnome/Wayland desktop
- Debian

sudoku: this app should change its window title but this doesn't happen
in my test environment. To test you can use the "Difficulty" menu.
That's most probably a Weston bug, because the title changes correctly with
Mutter and KDE. ..

Hmm, Weston...


Note: the "cursor" demo displays FL_CURSOR_HAND correctly (a "hand") but
FL_CURSOR_NS is shown as the "normal" cursor.
In my hands (Debian or Ubuntu in a virtual machine), the cursor demo doesn't ever
change the cursor shape with weston, although all required shapes are found by the adequate
Wayland function (wl_cursor_theme_get_cursor). The same cursor executable works
flawlessly with Mutter and KDE. For me, that's a weston bug.

Hmm, Weston again...


In general terms, my feeling now is that Weston is not really usable (yet?) in a desktop
environment, whereas gnome's Mutter and KDE support much better all window
operations (resize, redraw, hide, show, rename, cursor changes, etc…) expected in a desktop setting. It's also
what I read in weston's presentation in its own source repository :
"Weston is the reference implementation of a Wayland compositor, as well as a useful environment in and of itself.

Out of the box, Weston provides a very basic desktop, or a full-featured environment for non-desktop uses…

If you are after a more mainline desktop experience, the GNOME and KDE projects provide full-featured desktop environments built on the Wayland protocol."


I take it that Weston is not a useful test environment. It was easy to use for me (I just ran `weston`) but I recognize that this doesn't help much for FLTK development. I'll go for my further tests with another environment later.


I also read that the gnome desktop can be installed under Linux Mint.


Yes, I think it's possible (not sure if I have it already, need to log out to see). I have several DE's available, including Gnome and FVWM. Cinnamon is my default DE. I'll try how I can effectively test Wayland. I'm also sure that I configured one of my VM's to use Gnome+Wayland and I'll give this one a try.

Albrecht Schlosser

unread,
Oct 19, 2021, 10:00:23 AM10/19/21
to fltkc...@googlegroups.com
I'm now able to use my Linux Mint 20 with a "Gnome/Wayland" session.

For those interested in the problems and the solution: I had all required packages installed but I could not select the Wayland session from the login screen: I had two "Gnome" sessions that did the same (Gnome on Xorg). I found the following article helpful: https://askubuntu.com/questions/895730/how-to-start-gnome-wayland-desktop-from-lightdm

As the article describes I had two `gnome.desktop` files in /usr/share/xsessions/ and /usr/share/wayland-sessions/, respectively. The one in /usr/share/xsessions/ was a link to `gnome-xorg.desktop`. The only thing I had to do was to remove that link, then I could select either Gnome/X11 or Gnome/Wayland. The only drawback on my system was that the mouse didn't work after switching to Wayland (trackpad worked). After unplugging and plugging the USB cable back in it worked.


More FLTK/Wayland test results below...


On 10/19/21 12:55 PM Albrecht Schlosser wrote:
threads: sluggish like glpuzzle when trying to stop the demo (delay ~5
seconds in my tests).

Both threads and glpuzzle demos are still sluggish and hard to stop.


sudoku: this app should change its window title but this doesn't happen

This works fine now in the Gnome/Wayland session.


Note: the "cursor" demo displays FL_CURSOR_HAND correctly (a "hand") but
FL_CURSOR_NS is shown as the "normal" cursor.

This is still an issue in the Gnome/Wayland session. The FL_CURSOR_NS cursor doesn't display in both the `tile` and the `cursor` demos. Can you please verify that you can see this cursor (a vertical double arrow).

Another interesting (positive) observation is drawing speed with GL (fractals demo). The X11 and the Wayland versions show a very similar frame rate (in tree/6 mode about 59 fps when run alone). I attach a screenshot of both programs side-by-side which shows a small difference (but this is to be expected).

Unfortunately we don't have a similar drawing speed comparison for X11 vs. Wayland (Cairo) drawing.

fractals_side-by-side.png

Manolo

unread,
Oct 19, 2021, 12:13:22 PM10/19/21
to fltk.coredev
Le mardi 19 octobre 2021 à 16:00:23 UTC+2, Albrecht Schlosser a écrit :
Note: the "cursor" demo displays FL_CURSOR_HAND correctly (a "hand") but
FL_CURSOR_NS is shown as the "normal" cursor.

This is still an issue in the Gnome/Wayland session. The FL_CURSOR_NS cursor doesn't display in both the `tile` and the `cursor` demos. Can you please verify that you can see this cursor (a vertical double arrow).
The filename used for FL_CURSOR_NS was not optimal. The problem should be fixed now.

Albrecht Schlosser

unread,
Oct 19, 2021, 12:30:09 PM10/19/21
to fltkc...@googlegroups.com
On 10/19/21 6:13 PM Manolo wrote:
The filename used for FL_CURSOR_NS was not optimal. The problem should be fixed now.

Yep, thanks. Tested with Weston. ;-)

Manolo

unread,
Oct 19, 2021, 1:24:45 PM10/19/21
to fltk.coredev
Le lundi 18 octobre 2021 à 14:42:15 UTC+2, Albrecht Schlosser a écrit :
 
glpuzzle: very slow spinning when you drag the mouse on the board.
Hitting 'space' or 'n' key which should stop spinning reacts delayed
rather than immediately. There seems to be a very long "pipeline" of
events to be serviced before the app reacts. Even the window close
button seems to react delayed while the puzzle is spinning.
That should be fixed now, at least with gnome and KDE.

Albrecht Schlosser

unread,
Oct 19, 2021, 5:28:02 PM10/19/21
to fltkc...@googlegroups.com
Great, thanks!

I could not yet test with gnome (likely tomorrow) but a quick test with Weston (sic!) shows it's much more responsive and the close button works fine.

Reply all
Reply to author
Forward
0 new messages