Towards a Wayland platform for the FLTK library ?

[Manolo]

I'd like to invite fellow FLTK developpers to discuss the possibility of
adding a Wayland platform to the FLTK library.

My proposal is in branch "wayland" of https://github.com/ManoloFLTK/fltk
See file README.Wayland.txt therein for installation instructions, including
a short list of required Debian packages.
That software should hopefully install on any Wayland-running Linux system.
It's been tested on Debian and Ubuntu.
At this time, the wayland branch is not complete but quite advanced :
all test/ and examples/ apps build and run.

Users can run xwininfo in a terminal, click on any FLTK window using this new code,
and conclude that such windows are not X11-based, in contrast to what happens with
FLTK programs for the X11 platform.

The "wayland" branch doesn't require any change to the platform-independent FLTK
code. It's expected that any FLTK app should link and mostly run as a Wayland client
program. `fltk-config --cxxflags --ldflags` can be used in makefiles as usual.
Nevertheless, X11-specific code delimited by
#if !defined(__APPLE__) && !defined(_WIN32)
... X11-specific code ...
#endif
will choke at compile-time because it will expose X11-specific function calls. Such
source code should be changed to
#if !defined(__APPLE__) && !defined(WIN32) && !defined(__WAYLAND__)
... X11-specific code ...
#endif

OpenGL and GLUT are supported as for other FLTK platforms. OpenGL3 is supported too,
but a minor source code change is required after the glewInit() call :
  GLenum err = glewInit(); // defines pters to functions of OpenGL V 1.2 and above
#ifdef __WAYLAND__
  if (err == GLEW_ERROR_NO_GLX_DISPLAY) err = GLEW_OK;
#endif
That's because glewInit() returns an error code value in the Wayland context.

The Wayland protocol accomodates either client-based or server-based window
decoration. The Gnome Wayland implementation does not contain server-based
window decoration and instead expects each client program to decorate its windows.
For that reason, the FLTK library is extended in my proposal by a library, libdecor,
(see https://gitlab.gnome.org/jadahl/libdecoration) which produces window decoration
for each FLTK client program. That library is governed by the MIT license which
allows unrestricted use, even in a commercial setting, but asks for a copy of the
license to be included in any copy of the software.

I believe it's too early at this point for you, fellow developers, to send "this
doesn't work" messages, but expect messages about attempts to install the new branch
and to build full-size FLTK apps, and about the opportunity of a Wayland FLTK platform.

Manolo

[Albrecht Schlosser]

On 6/6/21 11:40 AM Manolo wrote:
> I'd like to invite fellow FLTK developpers to discuss the possibility of
> adding a Wayland platform to the FLTK library.

We've been asked (not many, but a few, countable) times about our plans
to add Wayland support to FLTK. I was about to look how this would be
done a few times, but now I see you did it. Awesome!

> My proposal is in branch "wayland" of https://github.com/ManoloFLTK/fltk
> See file README.Wayland.txt therein for installation instructions,
> including
> a short list of required Debian packages.
> That software should hopefully install on any Wayland-running Linux
> system.
> It's been tested on Debian and Ubuntu.
> At this time, the wayland branch is not complete but quite advanced :
> all test/ and examples/ apps build and run.

I'll try that ASAP, but likely not tomorrow because I need to do some
other stuff.

> The "wayland" branch doesn't require any change to the
> platform-independent FLTK
> code. It's expected that any FLTK app should link and mostly run as a
> Wayland client
> program. `fltk-config --cxxflags --ldflags` can be used in makefiles
> as usual.
> Nevertheless, X11-specific code delimited by
> #if !defined(__APPLE__) && !defined(_WIN32)
> ... X11-specific code ...
> #endif
> will choke at compile-time because it will expose X11-specific
> function calls. Such
> source code should be changed to
> #if !defined(__APPLE__) && !defined(WIN32) && !defined(__WAYLAND__)
> ... X11-specific code ...
> #endif

Thanks for your notes. This could turn out helpful.

Regarding the code changes: WOW, that's a lot of code! The following is
just for my curiosity:

I'm seeing also that much code has been copied which might not be needed
due to the driver structure. What are your plans, will you do a mass
cleanup when the Wayland code is (almost) finished? I'm asking because
I'm concerned about duplicated code. One example seems to be timer
related code which could be reused rather than duplicated etc. etc.. I
take it that you first copied the entire driver code and are now working
on fleshing out the needed changes and what doesn't need to be changed.
Is that about correct?

> The Wayland protocol accomodates either client-based or server-based
> window
> decoration. The Gnome Wayland implementation does not contain server-based
> window decoration and instead expects each client program to decorate
> its windows.
> For that reason, the FLTK library is extended in my proposal by a
> library, libdecor,
> (see https://gitlab.gnome.org/jadahl/libdecoration) which produces
> window decoration
> for each FLTK client program. That library is governed by the MIT
> license which
> allows unrestricted use, even in a commercial setting, but asks for a
> copy of the
> license to be included in any copy of the software.

Interesting. I see that you added the library to the FLTK repo. Are
there plans to (finally) bundle it or would we take it as a prerequisite
to be installed by developers? Generally I'd prefer the latter, but I
don't know how well it is supported by (Linux) distros. Can you share
your thoughts about this?

> I believe it's too early at this point for you, fellow developers, to
> send "this
> doesn't work" messages, but expect messages about attempts to install
> the new branch
> and to build full-size FLTK apps, and about the opportunity of a
> Wayland FLTK platform.

Looking forward to install and test! I'll let you know about my results
and hopefully others will try as well.

[Bill Spitzak]

This all seems like a good idea.

Using that existing libdecor code is probably an ok start, but I would like to see it done reusing as much functionality from FLTK as possible. It does look like that code is pretty minimal (ie it does not link with GTK) so that is a relief. In the end the FlWindow object would do all of this.

I assume this is using Cairo for rendering? You should, as that is what the titlebar code is using. The Cairo code needs to be fixed up so it is an acceptable backend for FLTK, and use the same cairo api in both the X11 and Wayland versions.

--
You received this message because you are subscribed to the Google Groups "fltk.coredev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fltkcoredev...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/fltkcoredev/2f54295b-a4d4-ecb2-c62b-14668d0fd70f%40online.de.

[Manolo]

Le dimanche 6 juin 2021 à 21:03:01 UTC+2, Albrecht Schlosser a écrit :

I'll try that ASAP, but likely not tomorrow because I need to do some
other stuff.

I'm looking forward to your feedback.

Regarding the code changes: WOW, that's a lot of code!

Yes. Everything related to windows, drawing, events, keyboard, pointers, cursors

requires complete rewriting.

The following is just for my curiosity:

I'm seeing also that much code has been copied which might not be needed
due to the driver structure. What are your plans, will you do a mass
cleanup when the Wayland code is (almost) finished? I'm asking because
I'm concerned about duplicated code. One example seems to be timer
related code which could be reused rather than duplicated etc. etc.. I
take it that you first copied the entire driver code and are now working
on fleshing out the needed changes and what doesn't need to be changed.
Is that about correct?

Yes. I've focused till now on building a running platform. Shared code

between X11 and Wayland platforms could be put in an Fl_Linux_System_Driver

from which Fl_Wayland_System_Driver and Fl_X11_System_Driver could derive.

Interesting. I see that you added the library to the FLTK repo. Are
there plans to (finally) bundle it or would we take it as a prerequisite
to be installed by developers? Generally I'd prefer the latter, but I
don't know how well it is supported by (Linux) distros. Can you share
your thoughts about this?

libdecor is only at version 0.1 now, so it's not yet in Debian Linux distros.

That's why I propose to bundle it in FLTK as we do with libz, libpng, libjpeg and nanosvg.

Its author, Jonas Ådahl, is also one of the two maintainers of the xdg-shell stable

Wayland protocol in charge of creating Wayland desktop windows

(see https://github.com/wayland-project/wayland-protocols/tree/main/stable/xdg-shell).

Thus, libdecor is apparently code from the heart of the Wayland project.

Alternatively, if another library is available to decorate FLTK Wayland windows, I'm ready

to examine it. My first concern was that libdecor's license should be compatible with FLTK's.

[Manolo]

Le lundi 7 juin 2021 à 00:03:51 UTC+2, spi...@gmail.com a écrit :

This all seems like a good idea.

Thanks.

Using that existing libdecor code is probably an ok start, but I would like to see it done reusing as much functionality from FLTK as possible. It does look like that code is pretty minimal (ie it does not link with GTK) so that is a relief. In the end the FlWindow object would do all of this.

libdecor is used both by the FLTK library and by a component of the Wayland system itself (the compositor I believe).

That's why it's necessarily a shared library which plugs into the compositor.

That also makes it a software requiring deep Wayland knowledge.

Thus, using an existing library is an attractive solution.

I assume this is using Cairo for rendering? You should, as that is what the titlebar code is using. The Cairo code needs to be fixed up so it is an acceptable backend for FLTK, and use the same cairo api in both the X11 and Wayland versions.

Yes. All drawing is done using Cairo, and Pango for text.

Thus, there's now a complete Cairo+Pango-based graphics driver in he Wayland branch,

which could be used by the X11 platform too. That would bring antialiasing to the X11 platform.

[Albrecht Schlosser]

On 6/7/21 8:44 AM Manolo wrote:

Le dimanche 6 juin 2021 à 21:03:01 UTC+2, Albrecht Schlosser a écrit :

I'll try that ASAP, but likely not tomorrow because I need to do some
other stuff.

I'm looking forward to your feedback.

Well, not really much feedback, I just played with the demo programs. I'm really impressed how well everything is already. Great job!

I used a VM (Ubuntu) where I had installed Wayland some time ago for tests. Almost all programs run fine and smoothly.


Some observations:

The "graphics speed test" (test/unittests - schemes test - resize window) works *MUCH* faster than my tests with Windows/gdi+ in a VM on my Linux Notebook (supposedly a very similar VM config).

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?

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.

Not all cursors appear as they should (test/cursor).

Screen scaling (ctrl/+/-/0) doesn't seem to work yet. Maybe in GL windows though (not sure). I've seen some weird effects.

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)


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.

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?

Manolo, would you like me to add CMake support? I'd like to help if I can.

[Albrecht Schlosser]

On 6/7/21 9:03 PM Albrecht Schlosser wrote:
> 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.

Screenshot attached.

[Bill Spitzak]

Looks like the z buffering got disabled somehow

--
You received this message because you are subscribed to the Google Groups "fltk.coredev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fltkcoredev...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/fltkcoredev/eccc8fa7-ccb8-4882-5de4-ca59d6f847df%40online.de.

[Greg Ercolano]

On 6/7/21 12:03 PM, Albrecht Schlosser wrote:

On 6/7/21 8:44 AM Manolo wrote:

Le dimanche 6 juin 2021 à 21:03:01 UTC+2, Albrecht Schlosser a écrit :

I'll try that ASAP, but likely not tomorrow because I need to do some
other stuff.

I'm looking forward to your feedback.

Well, not really much feedback, I just played with the demo programs. I'm really impressed how well everything is already. Great job!

    I don't have wayland here, but this sounds super impressive.
    Way to go Manolo, you're amazing!

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?

    Pretty sure X11 when used locally now uses IPC + shared memory when running locally,
    unix domain sockets instead of the overhead of TCP/networking.

    I have a vague memory that Silicon Graphics donated some code to X11 to improve the speed
    of rendering under X11, but I can't remember if it was specific to OpenGL (GLX), or included X11
    as a whole (Xsgi).

    MIT was behind a lot of improvements too, I don't remember the history very well.

    There may be more details burried in here:

    [1] https://en.wikipedia.org/wiki/Xsgi
    [2] https://en.wikipedia.org/wiki/X_Window_System

[Bill Spitzak]

I think there is some mistakes in current FLTK, in particular the "Driver" api, which uses virtual functions for no reason whatsoever as the called code is chosen at compile time, and as seen here the design makes it really difficult to share code. Would prefer to use #if statements like they are supposed to. I don't consider the current design readable or maintainable. I may be missing some function of Driver where more than one can be used, please correct me if I am wrong.

The "Device" is somewhat useful as it allows you to draw widgets in GL windows. I think there is also an attempt to allow it to print, though I am unclear if it is actually possible to use it for that and if anybody has done so. I still feel the number of virtual functions on it is excessive.

It sounds like Cairo is nowhere near as slow as others have claimed. It would be great to get a real working implementation that can be used both by this and X11. I think all transformations have to be done by the calling code, as there is a need to adjust all paths for fill and stroke to remove antialiasing on horizontal and vertical lines, and allow 1-pixel lines to be usable. This indicates to me that transforms at least can be removed from the Device virtual functions.

Read through the libdecor code and it appears to be drawing everything directly. There is a "plugin", perhaps with the intention that the style of the window borders can change by changing the plugin, but I don't agree with this as the api to the plugin is going to swiftly grow to a baroque monstrosity, just like every other attempt to control the borders. There was a good reason Wayland wanted CSD. I personally do not see any problem with drawing the window borders ourselves, any complaint that they look different is IMHO not logical if the difference in appearance of every other widget is considered acceptable. Also not using this library will mean a single Wayland surface can be used, instead of two.

[Albrecht Schlosser]

On 6/7/21 10:01 PM Bill Spitzak wrote:
> I think there is some mistakes in current FLTK, in particular the
> "Driver" api, which uses virtual functions for no reason whatsoever as
> the called code is chosen at compile time, and as seen here the design
> makes it really difficult to share code. Would prefer to use #if
> statements like they are supposed to. I don't consider the current
> design readable or maintainable. I may be missing some function of
> Driver where more than one can be used, please correct me if I am wrong.

It's true that the selection of the standard display and system driver
is done at library build time. However, the driver design was chosen to
get rid of the unmaintainable #ifdef stuff. Currently there should only
be #if statements to differentiate compilers and/or options (for
instance Xft vs Pango, VS (MSVC) vs. GNU, etc.). You can really use more
than one graphics driver (although still only one at a time) for
printing (Fl_Printer), copying to the clipboard (Fl_Copy_Surface),
Fl_PostScript (files) and Fl_Offscreen. This is all done by changing the
driver(s) on the fly. I'm using this in some applications. For an
example see test/device.cxx (the code may be historically grown and not
as clean as possible but it shows the options).

Regarding the driver selection at build time: I would also like to see
an option to combine two or more "platforms" in one executable program,
i.e. in one FLTK library. The idea is to decide at program startup which
"driver" we want to use, for instance X11 for remote display, macOS
native display driver, or (in the future) Wayland or Cairo. An
environment variable or commandline switch would then decide at program
startup which device/driver to use on platforms that allow different
connections. This should not be difficult to achieve...

> The "Device" is somewhat useful as it allows you to draw widgets in GL
> windows. I think there is also an attempt to allow it to print, though
> I am unclear if it is actually possible to use it for that and if
> anybody has done so. I still feel the number of virtual functions on
> it is excessive.

Yes, it is used for printing and even more stuff (see above). And it
works pretty well. A recent extension is to "draw" to an Fl_SVG_Surface
which eventually outputs real SVG files.

The number of virtual functions may be excessive in some parts (it's the
'.0' version), I'm sure there's room for improvement.

> It sounds like Cairo is nowhere near as slow as others have claimed.
> It would be great to get a real working implementation that can be
> used both by this and X11.

... which may be a logical step when the Wayland platform is done as
Manolo wrote already. Experience with Wayland is a good first step
(let's do one step after the other) before we go to the next (Cairo)
device. I could also have imagined to create a Cairo driver on X11
first, before Wayland, but now Wayland won.

> I think all transformations have to be done by the calling code, as
> there is a need to adjust all paths for fill and stroke to remove
> antialiasing on horizontal and vertical lines, and allow 1-pixel lines
> to be usable. This indicates to me that transforms at least can be
> removed from the Device virtual functions.

I'm not sure what this means.

> Read through the libdecor code and it appears to be drawing everything
> directly. There is a "plugin", perhaps with the intention that the
> style of the window borders can change by changing the plugin, but I
> don't agree with this as the api to the plugin is going to swiftly
> grow to a baroque monstrosity, just like every other attempt to
> control the borders.

ISTR that the "plugin" is really for defining other border and
decoration styles. I think I read about this in the README files of
libdecor in connection with setting up the demo program or something
like that.

> There was a good reason Wayland wanted CSD.

What is CSD? Client Server XXX ???

> I personally do not see any problem with drawing the window borders
> ourselves, any complaint that they look different is IMHO not logical
> if the difference in appearance of every other widget is considered
> acceptable. Also not using this library will mean a single Wayland
> surface can be used, instead of two.

I agree that this would be logical. I can't speak for Manolo but I think
using a library was considered easier than writing everything from
scratch. Would your (Bill's) old flwm code be helpful in doing window
decorations and stuff? Should be take a look at it? It's still available
somewhere...

[Greg Ercolano]

On 6/7/21 1:51 PM, Albrecht Schlosser wrote:

There was a good reason Wayland wanted CSD.

What is CSD? Client Server XXX ???

Pretty sure that's "Client Side Decorations"
https://blogs.gnome.org/tbernard/2018/01/26/csd-initiative/

[Albrecht Schlosser]

Oh, yes, that makes sense. And thanks for the link. Reading ...

[Ian MacArthur]

On 7 Jun 2021, at 20:03, Albrecht Schlosser wrote:
>
> I used a VM (Ubuntu) where I had installed Wayland some time ago for tests. Almost all programs run fine and smoothly.

> 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.

I would not preclude the possibility that the VM is involved in that misbehaviour - I was doing some testing on (IIRC Fedora) VM and the GL rendering was a bit glitchy.
The same binary running native on another machine was fine.
(The Fedora VM was because the end-user was on RHEL-something-or-other and I was working on debian, so I just wanted to see what happened on something more RHEL-like. The GL misbehaviour caused me some distress. But apparently the end-user did not see that. so I guess it was OK on their machines...)

[Bill Spitzak]

What I meant for Device was to replace it with code like this:

#if X11

#include <X11code.C>

#elif Windows

#include <Windowscode.C>

...

This is what was attempted in FLTK 2.

This should result in something exactly as maintainable as Device virtual functions, but there is no overhead and mistakes show up as unlinkable code.

It may be plausible to use Device to make a program that works on different devices but a lot of stuff, in particular timeouts and polling, are in it and there is just no way you can switch that to a different one.

--
You received this message because you are subscribed to the Google Groups "fltk.coredev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fltkcoredev...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/fltkcoredev/60E28EC3-E2DE-4B98-B0B9-C8AADA9CE3C3%40gmail.com.

[Ian MacArthur]

On 7 Jun 2021, at 21:01, Bill Spitzak wrote:
>
> I think there is some mistakes in current FLTK, in particular the "Driver" api, which uses virtual functions for no reason whatsoever as the called code is chosen at compile time, and as seen here the design makes it really difficult to share code. Would prefer to use #if statements like they are supposed to. I don't consider the current design readable or maintainable. I may be missing some function of Driver where more than one can be used, please correct me if I am wrong.

I think the *idea* (if not yet the actuality) of this is that at some point it stops being a compile time option and becomes more of a runtime option: indeed X11 vs. Wayland (or GDI vs. GDI+) might be ideal cases where that might come into play... But not quite yet.

> The "Device" is somewhat useful as it allows you to draw widgets in GL windows. I think there is also an attempt to allow it to print, though I am unclear if it is actually possible to use it for that and if anybody has done so. I still feel the number of virtual functions on it is excessive.

The printing support works pretty well, I’ve used it a fair bit and been quite pleased with the outcomes...
I have no opinion on what constitutes “too many” virtual functions. (Though, if the compiler can resolve the types statically, and often it can, then the virtualisation may be “free” at that point anyway. Which doesn’t help readability, I concede, but it’s helpful for runtimes.)

> It sounds like Cairo is nowhere near as slow as others have claimed.

It can be - just when you think it’s all going so well, it sneaks around and sticks you from behind!
There’s just “some things” on “some machines” where it suddenly runs like treacle; and I’m not even sure if it is the *same* things in each case...

[Greg Ercolano]

On 6/7/21 2:26 PM, Bill Spitzak wrote:

What I meant for Device was to replace it with code like this:

#if X11

#include <X11code.C>

#elif Windows

#include <Windowscode.C>

I had used that technique in the native file chooser, but it was changed.

That technique was generally recommended IIRC in an old O'Reilly book
on multiple platform code management I've had for decades now.

[Albrecht Schlosser]

And that's exactly the point. It's decades old!

This type of code is not at all scalable (by platform). You can see this in our old (1.3) code that has exactly that, with the (above missing) #else case. It was usually something like:

#ifdef _WIN32 // Windows
...
#elif defined(__APPLE__) // macOS
...
#else // X11
...
#endif

which *implied* that the #else case is Unix/Linux/X11. This also precluded (basically) using X11 on macOS (which is definitely possible). Whenever you add another device/platform/driver/backend (call it as you like) you need to add yet another #elif case at *uncountable* places. That's the nightmare we got rid of by moving to the "driver" structure.

This driver structure is unlimited extensible by adding "just another class" with selected virtual methods that need to be overridden (sharing the code of not overridden methods). This is the ideal case. You can see it in the drawing code of the Wayland graphics driver which reuses existing Cairo driver code.

In practice, I admit, this is not as easy as it sounds. It tends to "copy and paste" code from one driver to another one, fix the "few statements" that need to be replaced, and then you end up with lots of duplicated code that needs to be maintained (mainly in the system specific parts). That's bad and not intended. The "correct" way needs a finer granularity of functions (virtual methods) and a good design. This is harder to achieve but possible (and that's why I asked Manolo about the current status of his edits and his plans for completion).

Example: We have three totally different ways to implement timer related code: Unix/Linux (Posix), Windows, and macOS. This led to incompatibilities (macOS) and lack of accuracy (Windows). I don't want to write about more details here, but I believe that a better implementation would be doable in platform-agnostic code with only minor system specific functions (here: virtual driver methods). Copying the Linux/Unix/Posix code to "Wayland drivers" (which has been done during the development) is NOT the final solution (hopefully). That's only one example...

[Bill Spitzak]

FLTK2 did change it so there was not a fallback in the if statements, making it easy to rearrange them and to make it clear when things were for X11. I certainly agree this should be done here too.

What I was saying is that the contents of the if statements were #include statements. This put each machine's code in it's own file, without any overhead of virtual functions.

--
You received this message because you are subscribed to the Google Groups "fltk.coredev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fltkcoredev...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/fltkcoredev/13c59d6a-ef8b-298b-c932-e3858c8803dc%40online.de.

[Manolo]

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).

[Manolo]

Le lundi 7 juin 2021 à 22:02:00 UTC+2, spi...@gmail.com a écrit :

Read through the libdecor code and it appears to be drawing everything directly. There is a "plugin", perhaps with the intention that the style of the window borders can change by changing the plugin, but I don't agree with this as the api to the plugin is going to swiftly grow to a baroque monstrosity, just like every other attempt to control the borders. There was a good reason Wayland wanted CSD. I personally do not see any problem with drawing the window borders ourselves, any complaint that they look different is IMHO not logical if the difference in appearance of every other widget is considered acceptable. Also not using this library will mean a single Wayland surface can be used, instead of two.

Here's an investigation with gdb on program test/hello searching for what context calls static function draw_title_text()

from libdecor's src/plugin/cairo/libdecor-cairo.c which draws the text of window titlebars :

1) When a window is first created, libfltk code calls libdecor code which draws the window title :

#0  0x00007ffff7d3039f in draw_title_text ()
    at /media/sf_macshared/wayland/fltk/lib/libdecor-0.1.so
#1  0x00007ffff7d30c25 in draw_component_content ()
    at /media/sf_macshared/wayland/fltk/lib/libdecor-0.1.so
#2  0x00007ffff7d319c0 in draw_border_component ()
    at /media/sf_macshared/wayland/fltk/lib/libdecor-0.1.so
#3  0x00007ffff7d31b89 in draw_title_bar ()
    at /media/sf_macshared/wayland/fltk/lib/libdecor-0.1.so
#4  0x00007ffff7d31c5d in draw_decoration ()
    at /media/sf_macshared/wayland/fltk/lib/libdecor-0.1.so
#5  0x00007ffff7d31ee3 in libdecor_plugin_cairo_frame_commit ()
    at /media/sf_macshared/wayland/fltk/lib/libdecor-0.1.so
#6  0x00007ffff7d2c6c0 in libdecor_frame_commit ()
    at /media/sf_macshared/wayland/fltk/lib/libdecor-0.1.so
#7  0x000000000043ab8a in handle_configure(libdecor_frame*, libdecor_configuration*, void*) (frame=0x4d5c00, configuration=0x533490, user_data=0x4c1380)
    at drivers/Wayland/Fl_Wayland_Window_Driver.cxx:747
 

2) Each time the window is deactivated or activated, its titlebar gets redrawn.
This is done by libfltk calling libwayland-client.so which calls libffi.so (what is it?)

which calls libdecor-0.1.so to draw the title :

#0  0x00007ffff7d3039f in draw_title_text ()
    at /media/sf_macshared/wayland/fltk/lib/libdecor-0.1.so
#1  0x00007ffff7d30c25 in draw_component_content ()
    at /media/sf_macshared/wayland/fltk/lib/libdecor-0.1.so
#2  0x00007ffff7d319c0 in draw_border_component ()
    at /media/sf_macshared/wayland/fltk/lib/libdecor-0.1.so
#3  0x00007ffff7d31b89 in draw_title_bar ()
    at /media/sf_macshared/wayland/fltk/lib/libdecor-0.1.so
#4  0x00007ffff7d31c5d in draw_decoration ()
    at /media/sf_macshared/wayland/fltk/lib/libdecor-0.1.so
#5  0x00007ffff7d32d72 in synthesize_pointer_enter ()
    at /media/sf_macshared/wayland/fltk/lib/libdecor-0.1.so
#6  0x00007ffff7d32ecf in pointer_enter ()
    at /media/sf_macshared/wayland/fltk/lib/libdecor-0.1.so
#7  0x00007ffff7374d1d in  () at /lib/x86_64-linux-gnu/libffi.so.7
#8  0x00007ffff7374289 in  () at /lib/x86_64-linux-gnu/libffi.so.7
#9  0x00007ffff7db22d2 in  () at /lib/x86_64-linux-gnu/libwayland-client.so.0
#10 0x00007ffff7dae97a in  () at /lib/x86_64-linux-gnu/libwayland-client.so.0
#11 0x00007ffff7db003c in wl_display_dispatch_queue_pending ()
    at /lib/x86_64-linux-gnu/libwayland-client.so.0
#12 0x0000000000436940 in fd_callback(int, wl_display*)
    (unused=3, display=0x4b45f0)
    at drivers/Wayland/Fl_Wayland_Screen_Driver.cxx:925
#13 0x000000000044148c in Fl_Wayland_Screen_Driver::poll_or_select_with_delay(double) (this=0x4b43a0, time_to_wait=1e+20) at drivers/Wayland/Fl_wayland.cxx:225
#14 0x00000000004371cc in Fl_Wayland_Screen_Driver::wait(double)
    (this=0x4b43a0, time_to_wait=1e+20)
    at drivers/Wayland/Fl_Wayland_Screen_Driver.cxx:1146
#15 0x0000000000407aa6 in Fl::wait(double) (time_to_wait=1e+20) at Fl.cxx:449
#16 0x0000000000407ad3 in Fl::run() () at Fl.cxx:469

This, I interpret as showing that a shared library plugin is necessary for libdecor. Am I wrong?

FLTK could stop pulling in future libdecor updates when we would feel it's becoming

'a baroque monstrosity'.

I understand that FLTK could do CSD drawing a custom titlebar in the same surface as the window main area.

I see this path has not been followed by libdecor. May be it's because libdecor wants to be compatible

with desktops (and I believe KDE is one) that provide server-side decoration (SSD).

[Manolo]

Test apps resize-example* should run now on Wayland after git pull.

[Albrecht Schlosser]

On 6/8/21 9:30 AM Manolo wrote:

Here's an investigation with gdb on program test/hello searching for what context calls static function draw_title_text()

from libdecor's src/plugin/cairo/libdecor-cairo.c which draws the text of window titlebars :

1) When a window is first created, libfltk code calls libdecor code which draws the window title :

#0  ... (call stack elided)
 

2) Each time the window is deactivated or activated, its titlebar gets redrawn.
This is done by libfltk calling libwayland-client.so which calls libffi.so (what is it?)

FYI, from the docs of libffi:
"The libffi library provides a portable, high level programming interface to various calling conventions. This allows a programmer to call any function specified by a call interface description at run time. FFI stands for Foreign Function Interface."
https://github.com/libffi/libffi

This is obviously used to call plugins in a portable way.

which calls libdecor-0.1.so to draw the title :

#0  ...

This, I interpret as showing that a shared library plugin is necessary for libdecor. Am I wrong?

It seems like plugins are the used to implement actual decorations/themes:

From the docs (README) of libdecor:
"... libdecor will look for plugins in the target directory of the installation. Therefore, when running the demos directly from the build directory, no plugins will be found and the fallback plugin without any decorations will be used."
https://gitlab.gnome.org/jadahl/libdecoration

FLTK could stop pulling in future libdecor updates when we would feel it's becoming

'a baroque monstrosity'.

I understand that FLTK could do CSD drawing a custom titlebar in the same surface as the window main area.

I see this path has not been followed by libdecor. May be it's because libdecor wants to be compatible

with desktops (and I believe KDE is one) that provide server-side decoration (SSD).

Whatever the reasoning behing libdecor is and notwithstanding the option to draw only into one buffer I think that we can independently investigate if it makes sense for us to draw the decorations ourselves. I do also think that an option to not draw decorations at all (particularly the title bar) would be useful so programs can draw their own "header bar" if they are modified to do so. But this is a future issue and not necessary for functional evaluation of the Wayland port.

[Albrecht Schlosser]

On 6/7/21 11:21 PM Ian MacArthur wrote:
> On 7 Jun 2021, at 20:03, Albrecht Schlosser wrote:
>> 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.
> I would not preclude the possibility that the VM is involved in that misbehaviour - I was doing some testing on (IIRC Fedora) VM and the GL rendering was a bit glitchy.

That's a valid point, I've also seen VM setups that had issues with
OpenGL in the past.

But I think we can rule this out here. I tried both the X11 version and
the Wayland version of glpuzzle side by side on the Ubuntu VM and the
X11 version works well. There must be something different in the Wayland
version, see attached screenshot with a similar view of the scene.

I will also try to use another setup with Wayland on a bare metal Linux
system later.

[Albrecht Schlosser]

On 6/8/21 12:05 PM Manolo wrote:
> Test apps resize-example* should run now on Wayland after git pull.

Yep, confirmed. Thanks.

[Albrecht Schlosser]

On 6/8/21 8:52 AM Manolo wrote:

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.

Thanks, that's exactly what I had expected. Wayland is always "double buffered" and, from a user's point of view, Fl_Window will be functional identical to Fl_Double_Window on the Wayland platform.

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.

Neither do I, but my further test (see another message) seems to indicate that the wrong behavior is Wayland and not VM specific. Do you see this misbehavior too?

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?

Hmm, that's a pity. I don't know but I'm sure we can find a way to make our own cursors as a fallback if necessary.

Screen scaling (ctrl/+/-/0) doesn't seem to work yet. Maybe in GL windows though (not sure). I've seen some weird effects.

FTR, see attached image running "$ FLTK_SCALING_FACTOR=1.3 test/fullscreen" with both X11 (left side) and wayland (right image).

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/+/.

FLTK apps don't seem to honor the environment variable FLTK_SCALING_FACTOR completely (see image). The scaling factor is recognized though (scale: 1.30) in both cases.

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.

I can't find such a setting in my Ubuntu VM. I only have "Resolution" and "Fractional Scaling" (see screenshot).

They're not adaptive while running yet, though.

Do you think you can implement this too? ctrl/+/-/0 is IMHO an essential feature independent of the system/display setting.

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 will give it a try anyway. For me it's a valuable addition even for the testing phase, and I'm confident that we will add Wayland support sooner or later -- unless we find that it's not going to work which doesn't seem likely now, thanks to your awesome work so far.

I think, as long as you're developing the Wayland port it's okay to have it in your own fork. You could even create a PR so we (devs only) can also commit directly to your fork (if you like).

My suggestion is to rebase the branch from time to time so we are always in sync with the upstream master branch (please don't merge the master into your wayland branch though, this will only make things more difficult). I do also propose that we'll rebase and squash the wayland branch before the final merge to avoid having too many intermediate file versions in the main FLTK repository.

I would also appreciate feedback about use on a native Linux system (as opposed to a virtual machine).

I'll try to test on my bare metal Linux when time permits. I think I did already install 'weston' so I could maybe run it directly on my notebook. If that's not possible I can use another Debian Buster system on my ancient MacMini. ;-)

[Albrecht Schlosser]

On 6/8/21 2:30 PM Albrecht Schlosser wrote:

On 6/8/21 8:52 AM Manolo wrote:

I would also appreciate feedback about use on a native Linux system (as opposed to a virtual machine).

My test results follow...

I'll try to test on my bare metal Linux when time permits. I think I did already install 'weston' so I could maybe run it directly on my notebook.

FYI, from Wikipedia: "Weston is the reference implementation of a Wayland compositor also developed by the Wayland project."
https://en.wikipedia.org/wiki/Wayland_(display_server_protocol)#WESTON

Since I had already installed weston (Ubuntu package: weston, maybe together with some more '-dev' packages) I could build the FLTK wayland branch w/o installing anything else on my Linux Mint 20 system (which is based on Ubuntu 20.04 LTS).

I launched 'weston' which opened its own desktop window. All (FLTK) Wayland programs connect to this weston instance and show their windows on this weston desktop. Screenshot 'weston-wayland-x11.png' shows the weston desktop in the background, two FLTK Wayland programs on the left hand side, and two FLTK X11 programs on the right hand side in front, overlapping the weston window. The glpuzzle demo under Wayland exhibits the know issues.

For devs who can't test themselves I'm attaching the screenshot 'weston-fullscreen.png' so you can get an impression.

@Manolo: I showed intentionally the cursor FL_CURSOR_SE that (IIRC) did not show properly in my first Ubuntu test which seems to confirm what you wrote about cursor images.

Screenshot 'lines.png' shows a zoomed image of 'test/unittests:drawing lines' with pretty anti-aliased lines.


I also found a new bug which is described in attached 'wayland-error-in-client.txt': the first part shows the info displayed when running the program and clicking on 'fl_show_colormap()'. The program window disappears and lines 3-4 show an error message.

The "Error message in weston" is logged by the running 'weston' instance and may be interesting as well.

After this the running 'test/color_chooser' uses 100% CPU time and needs to be stopped with ctrl/c.


Other observations in this constellation with weston:

- mouse clicks seemed sometimes not to react immediately (maybe flushing the display was missing), but then it worked again flawlessly

- this also affected window resizing with the mouse (sometimes, not always)

- test/offscreen seemed to hang after the start, but after clicking on another window (multiple times IIRC) it seemed to work as expected

As I wrote above, these are observations running on my bare metal Linux Mint with weston. It is possible that the interaction with weston caused some of these effects. More tests with a "Wayland desktop system" like Ubuntu are needed.

[Albrecht Schlosser]

On 6/8/21 5:03 PM Albrecht Schlosser wrote:
>
> Other observations in this constellation with weston:
>
> - mouse clicks seemed sometimes not to react immediately (maybe
> flushing the display was missing), but then it worked again flawlessly
>
> - this also affected window resizing with the mouse (sometimes, not
> always)
>
> - test/offscreen seemed to hang after the start, but after clicking on
> another window (multiple times IIRC) it seemed to work as expected
>
> As I wrote above, these are observations running on my bare metal
> Linux Mint with weston. It is possible that the interaction with
> weston caused some of these effects. More tests with a "Wayland
> desktop system" like Ubuntu are needed.

I tested two more constellations with Weston in my Ubuntu VM:

(1) I logged in as a "normal" Ubuntu system running the Ubuntu Desktop,
installed weston, and launched weston from the terminal. This opened a
"Weston Desktop" as previously on my Linux Mint system.

(2) After I had installed Weston on the Ubuntu system I looged out and
logged in again. This time I had a new choice to use "Weston" as the
desktop system. I selected this and logged in.

In both constellations the "Compositor" is Weston. Both constellations
showed the same issues as described above, I'd say even worse than on my
native Linux system: button clicks not visible, need to click on another
window (change window focus), programs controlled by timers like
test/offscreen and test/blocks don't update their windows etc..

The conclusion is that the combination of FLTK + Weston is less reliable
(in other words: almost not usable) in the current implementation. Note
that I'm not saying it's FLTK's fault - I'm only saying that this
combination doesn't work well, whereas the Ubuntu compositor (whatever
it's called) which provides the "Ubuntu Wayland" desktop appears to work
much better with FLTK (or vice versa).

Since Weston is the "reference implementation" it would be interesting
to find out if our (FLTK Wayland) implementation lacks some
(communication) details or if Weston is (maybe) "not ready for
production use". Tests with other applications running under Weston
might shed some light on this question.

That said, I'm really impressed how well the FLTK Wayland port works
already. Did I say this already? Great job, Manolo!

[Manolo]

Le mardi 8 juin 2021 à 14:30:06 UTC+2, Albrecht Schlosser a écrit :

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.

I can't find such a setting in my Ubuntu VM. I only have "Resolution" and "Fractional Scaling" (see screenshot).

That's because enough pixels are required for the "Scale" button to appear. I see that 1440x900 is not enough,

whereas 1920x1200 has "Scale" appear.

[Manolo]

Le mardi 8 juin 2021 à 14:30:06 UTC+2, Albrecht Schlosser a écrit :

FLTK apps don't seem to honor the environment variable FLTK_SCALING_FACTOR completely (see image). The scaling factor is recognized though (scale: 1.30) in both cases.

FLTK on Wayland will now ignore  FLTK_SCALING_FACTOR until support for ctrl/+/-/0/ is programmed.
It supports Wayland's own scaling factor as explained before.