GL differences - X11 vs Wayland (WSL2, in case that matters!)

[imacarthur]

Background to this is that I was testing a rebuilt Windows PC so I installed WIn11, then got carried away and installed WSL2 / Ubuntu.

Firstly, actually getting WSL2 installed was a lot more hassle than the docs suggested, but it works, and FLTK builds and runs OK. Now it works it start/stops much faster than VirtualBox if I need to spin a Linux instance for some tests.

It also has Wayland, which none of my "real" Linux boxes do!

I built the tip of fltk-1.4 from this morning, so it has the "dual" back-end. I then ran the tests and examples either with or without "FLTK_BACKEND=x11" to compare.

Most things Just Worked. There are some peculiarities though... 

The window decorations look a bit odd; I assume that's our built-in libdecor? Not sure how to tell - in any case I think the title bar font is too large!

Apart from that, the majority of things seemed to be "the same" except:

- Under Wayland, the menus and choice drop-downs and so forth seem to jump about an awful lot, which is quite disconcerting. I assume that's a side effect of Wayland not providing any sensible mechanism for positioning a window? Looks pretty janky, anyway.

- There's some weird stuff going on with GL. Now, GL working at all is a step up (VirtualBox GL has never really worked for me!) but under X11 it works and seems broadly the same as I've seen on my "real" Linux boxes, albeit possible slower. Under Wayland, it seems even slower again (I was counting frame rate to try and measure that) and several of the tests (fractals, cube, glpuzzle) don't seem to have the background filled in, which is weird.

- The reported GL API in OpenGL3test is 3.3, which seems odd as the "native" Win11 build reports 4.6 - I guess that's something to do with the Mesa intermediary layer or such...

- Some tests (notably cube) run really slowly under Wayland; the same file invoked with 

FLTK_BACKEND=x11 ./cube

runs quickly with the cubes whizzing about. (This is noticeable in the glpuzzle test too, if you tell it to solve, the X11 version whizzes, the Wayland version crawls...)

Still, it's pretty neat that it works at all!

[Albrecht Schlosser]

On 11/30/22 17:31 imacarthur wrote:
> Background to this is that I was testing a rebuilt Windows PC so I
> installed WIn11, then got carried away and installed WSL2 / Ubuntu.
>

> ...

>
> I built the tip of fltk-1.4 from this morning, so it has the "dual"
> back-end. I then ran the tests and examples either with or without
> "FLTK_BACKEND=x11" to compare.
> Most things Just Worked.

Great! I still need to test WSL myself, but I mostly run Windows in a
Virtualbox VM under Linux which has its own issues. I would have to boot
my work system into Windows which I try to avoid as much as possible.

> There are some peculiarities though...
>
> The window decorations look a bit odd; I assume that's our built-in
> libdecor? Not sure how to tell - in any case I think the title bar
> font is too large!

This looks like the "Cairo" libdecor plugin (or built-in version). In my
builds this has a black background and the label fonts are too large.

You can get the "GTK" plugin if you install gtk3 development files. I
don't know if you can do this under WSL, but then you should get
"better" title bars with a more appropriate font.

> Apart from that, the majority of things seemed to be "the same" except:
>
> - Under Wayland, the menus and choice drop-downs and so forth seem to
> jump about an awful lot, which is quite disconcerting. I assume that's
> a side effect of Wayland not providing any sensible mechanism for
> positioning a window? Looks pretty janky, anyway.

Yes, unfortunately that's true. One notable difference is that the menus
start scrolling when the cursor reaches the main window borders as
opposed to the screen borders under X11. We could probably mitigate this
by better controlling the scroll speed to make it smoother but as it
stands we can't change the different "window vs. screen" behavior.

> - There's some weird stuff going on with GL. ...

Regarding GL issues I can't say anything useful. Maybe Manolo can.

> Still, it's pretty neat that it works at all!

Good to know, thank you for your report. ISTR that users reported
already that it worked but hearing this from a FLTK dev who may look
more at the details is great, thanks.

[imacarthur]

On Wednesday, 30 November 2022 at 17:22:19 UTC Albrecht Schlosser wrote:

On 11/30/22 17:31 imacarthur wrote:
>
> The window decorations look a bit odd; I assume that's our built-in
> libdecor? Not sure how to tell - in any case I think the title bar
> font is too large!

This looks like the "Cairo" libdecor plugin (or built-in version). In my
builds this has a black background and the label fonts are too large.

Yes, I poked at this a bit, it is the "cairo" libdecor titlebar I'm getting. It's ugly!

 

You can get the "GTK" plugin if you install gtk3 development files. I
don't know if you can do this under WSL, but then you should get
"better" title bars with a more appropriate font.

Looks like I can get the libgtk-3-blah stuff, including libgtk-3-dev under WSL (at least, that is to say that "apt search blah" lists them as available) but they don't seem to be installed by default, and (pretending to) install them flags quite a lot of dependencies to also pull in... I might just leave that alone for now!

Without having actually looked at this at all, I wonder if we can draw our own titlebar? Like, with fltk, I mean? 

It could hardly be uglier than what I'm getting, at any rate!

 

[Manolo]

The GTK-styled titlebar obtained with libgtk-3-dev is a much better solution because

FLTK apps will integrate much better the desktop and follow its future evolution.

[Bill Spitzak]

How come the desktops are not providing working libdecor plugins? Or is FLTK not finding and loading them?

--
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/52f8b649-90e4-4661-af1f-84869f0d75a1n%40googlegroups.com.

[Manolo]

Le mercredi 30 novembre 2022 à 21:49:48 UTC+1, Bill a écrit :

How come the desktops are not providing working libdecor plugins? Or is FLTK not finding and loading them?

 

The libdecor package is not yet in Linux distros. It's in Debian sid which is the testing version,

and it only has the cairo plugin there. The GTK plugin was a PR to libdecor till a few weeks ago.

For now, FLTK uses its built-in version of libdecor to draw GTK-styled titlebars. And this requires

libgtk-3-dev.

But FLTK is ready for the moment when libdecor plugins will become part of Linux distros

and will load libdecor plugins as soon as they'll appear.

[Bill Spitzak]

If fltk can define it's own fallback plugin it might be worth it to fix up the Cairo one some and include it with fltk.

--
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/a4ee1ba1-e43e-40dd-bf7a-e52016f30892n%40googlegroups.com.

[imacarthur]

On Wednesday, 30 November 2022 at 23:09:14 UTC Bill wrote:

If fltk can define it's own fallback plugin it might be worth it to fix up the Cairo one some and include it with fltk.

So (and I caution here that I only had a fairly cursory look...) what I think happens to "choose" the Wayland window decorator, with the current fltk-1.4 head is:

+ If Wayland is "not available" at runtime, OR if FLTK_BACKEND=x11 is set explicitly, then the X11 "traditional" code paths are run and decorations are provided by the X11 WM in the "normal" fashion we're all used to.

+ If Wayland is available, then:

++ If there is a *system* libdecor available, it is loaded and thereafter *it* decides what decorator plugin to run, presumably based on some system-wide setting? FWIW, I have not seen this work since the (one) system I have does not provide any system libdecor.

++ If there is no system libdecor, then we use the fltk built-in libdecor which:

+++ Will load a gtk-3 based plugin, IF libgtk-3-dev was available *when fltk was compiled* (libgtk-3 is not on my WSL2 test set-up)

+++ Else will load a Cairo based decorator plugin (since Cairo has to be available for our Wayland port anyway.)

As best I can tell, the libdecor we have "built-in" is pretty much "stock" so we do not have to work too hard to maintain it in the short term (and I assume that in the long term we expect system libdecor to become commonplace so the built-in version is less likely to be invoked?)

So: we could probably fix the cosmetic issues with the Cairo decorator plugin, but doing so would put our built-in code out-of-synch with upstream and hence be a maintenance burden. Still might be worth a stab (I say this without looking at what the decorator plugin code actually does at all!)

Or we could maybe add our own fltk-based decorator plugin, alongside the "stock" plugins, that will be called in preference to the gtk-3 or Cairo options, if the built-in libdecor is used? That way we can mess with the cosmetic aspects without altering the code from upstream at all.

But previous caveat applies - I have no clue whether that is feasible nor how hard it might be...

 

[Manolo]

The libdecor source code bundled in FLTK is unchanged relatively to what it is at its

home repository. We don't want to change that.

Since the cairo plugin is apparently not acceptable, the solution is to make the Wayland

FLTK platform require the libgtk-3-dev package, just like it requires already libpango1.0-dev.

In the future, when the GTK libdecor plugin will have become a Linux package,  FLTK can be made

to require either libgtk-3-dev or libdecor.

[Bill Spitzak]

What I don't understand is why the included libdecor is unable to load system-provided plugins. It should be the same code. If the system has it's own plugin it should be loaded and used no matter how fltk is compiled.

It does sound a lot like we need a better fallback plugin. Take the code for the cairo plugin and fix the font sizes. This can't be too hard. I would not add a dependency on GTK.

--

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/2d6592ac-e7c1-4573-9cc0-1a04eb26a053n%40googlegroups.com.

[Albrecht Schlosser]

On 12/1/22 21:20 Bill Spitzak wrote:

What I don't understand is why the included libdecor is unable to load system-provided plugins.

Because there are no such plugins yet. I'm sure it could do that.

... If the system has it's own plugin it should be loaded and used no matter how fltk is compiled.

Yes, *if* !

It does sound a lot like we need a better fallback plugin. Take the code for the cairo plugin and fix the font sizes. This can't be too hard.

I agree, this might be a better way than to rely on the GTK plugin that needs the GTK dev headers (which is a *lot*) if we compile it ourselves.

I would not add a dependency on GTK.

Currently it's optional (with the fallback to the Cairo plugin). But I agree that I wouldn't want a hard dependency on GTK.

[imm]

OK, so I stared at the plug-in code for a bit, starting from "How hard can it be to write our own?"

Harder than that, basically...

Observations: (in no particular order)

- if there were any system provided plugins the built-in loader would be able to load them; but there just don't seem to be many (any?) system provided plugins yet

- I really don't want a dependency on gtk3

- dependency on Cairo is unavoidable with Wayland & libdecor so we will always have that anyway 

- the Cairo plugin works well, it just looks a bit rough; Cairo can draw nicer things than that 

- adjusting the titlebar font looks trivial (will test tomorrow). TBH, I think the reason it's seems so big is actually a bug in the code, which I'll test for 

- ditto adjusting the colour scheme

- making our own version of the Cairo plugin takes us away from upstream, which is a "nuisance"

- we could possibly leave the stock Cairo decorator plugin as-is but add our own adjusted version (suitably renamed) alongside it; that may be easier to maintain?

- we (probably) can make a fltk based decorator plugin but it's not a 5 minute job...

--
Ian
From my Fairphone FP3

[Bill Spitzak]

I think the only code we want unchanged is the part that does dlopen of the plugin and calls it (what I think libdecor is). The plugin itself can be completely different, so only code for our fallback plugin needs to be included (this code will likely be a variation of the stock Cairo plugin, but that only needs to be noted with a comment in the code, not with an unmodified copy).

Since fltk compiled for Wayland is using Cairo anyway, it is probably ok that the plugin is using Cairo instead of fltk calls.

--
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/CAGFM6dazryVwjYYOP%3DyyGmuYebZUfTWsatA2OxO%2B_Fraz2gS6w%40mail.gmail.com.

[Manolo]

The single source file for the cairo plugin (libdecor/src/plugins/cairo/libdecor-cairo.c) begins

with assignments of constant variable values for the title font size, and the colors of title bar text

and background, in active and inactive states  :

static const size_t SYM_DIM = 14;      // font size
static const uint32_t COL_TITLE = 0xFF080706;     // background color - active
static const uint32_t COL_TITLE_INACT = 0xFF303030;  // background color - inactive
static const uint32_t COL_SYM = 0xFFF4F4EF;    // text color - active
static const uint32_t COL_SYM_INACT = 0xFF909090;       // text color - inactive

Developers are welcome to commit changes to these values to create what could be an FLTK-style

title bar. Change should be labelled with a comment to allow transmission of these

changes whenever the source file would change upstream.

[imacarthur]

On Friday, 2 December 2022 at 05:07:58 UTC Manolo wrote:

The single source file for the cairo plugin (libdecor/src/plugins/cairo/libdecor-cairo.c) begins

with assignments of constant variable values for the title font size, and the colors of title bar text

and background, in active and inactive states  :

static const size_t SYM_DIM = 14;      // font size

Yes - the tricky bit is that this size not only sets the font size, it also defines the dimensions of the max, min, close buttons and their symbols, so just changing this value isn't the best fix.

Rather, I think there's actually a bug in the plugin code.

Around line 2715 they have:

        pango_font_description_set_size(plugin_cairo->font, SYM_DIM * PANGO_SCALE);

but I think that is wrong, as I think that pango_font_description_set_size() expects a font size in points (72 dpi) and renders it to the display scale; but they have scaled it by PANGO_SCALE which I think *also* scales it up... Elsewhere that SYM_DIM is used (e.g. in drawing the max, min, close buttons) it is used without pre-scaling, so is in effect in Cairo display units (and hence smaller than the font will be rendered.) I think that is why the font looks too big compared to the other title bar components.

I replaced the call with:

        pango_font_description_set_absolute_size(plugin_cairo->font, SYM_DIM * PANGO_SCALE);

instead, as that will render the font in "display units" rather than points, and that certainly looks like a more credible size in my tests.

 

static const uint32_t COL_TITLE = 0xFF080706;     // background color - active
static const uint32_t COL_TITLE_INACT = 0xFF303030;  // background color - inactive
static const uint32_t COL_SYM = 0xFFF4F4EF;    // text color - active
static const uint32_t COL_SYM_INACT = 0xFF909090;       // text color - inactive

Yes - what I was hoping for was that we could do something like call Fl::get_system_colors(); to determine what these values should be, then set them based on that (though with some remapping since our colours are *not* the same format as this...) But calling a fltk C++ method from a plain-C plugin loader may not be ideal here...

 

Developers are welcome to commit changes to these values to create what could be an FLTK-style

title bar. Change should be labelled with a comment to allow transmission of these

changes whenever the source file would change upstream.

Yes - since we load the built-in via our fl_libdecor-plugins.c wrapper, we can tweak that to pull in a modified+renamed copy of  libdecor-cairo.c (say libdecor-cairo-modified.c or whatever, better name suggestions welcome!) and put any tweaks we fancy in there without altering the upstream code at all.

[Bill Spitzak]

I don't think the stuff read by Fl::get_system_colors() is working at all in newer desktops so it may be pointless to try to use it.

--
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/6b282c6a-3507-4658-bcfc-d06b38542c29n%40googlegroups.com.

[imm]

On Fri, 2 Dec 2022, 16:39 Bill Spitzak wrote:

I don't think the stuff read by Fl::get_system_colors() is working at all in newer desktops so it may be pointless to try to use it.

Which made me realize I hadn't thought that through anyway...

(If it's working) it attempts to read values from various X11 config files, and from various gnome and KDE settings. But in this case, running Wayland, a lot of those things may not exist at all, or be otherwise incompatible. I doubt the X11 config files have much bearing on the Wayland colour schemes for example.

Back to the drawing board then.