Strange Fl::screen_... results in 1.4

[Tigercat]

So I'm getting some strange results from the Fl::screen* functions with 1.4.0 in my code versus 1.3.5 (which is what my Gentoo system currently packages). I created a simple test case to show the differences.

In 1.3.5, my testcase outputs the following using the Fl::screen_count() and Fl::screen_work_area() methods:

GCC Version: 11.3.0
FLTK Version: 1.3.5
Known monitors: 3
Monitor 1: 3840x2160 (7680,0)
Monitor 2: 3840x2160 (0,0)
Monitor 3: 3840x2160 (3840,0) [Primary Screen]
Workspace: 11520x2160

This exactly matches my current configuration, which is three 4K monitors with the middle monitor (Monitor 3) being the primary screen. The WM is KDE/Plasma on Xorg.

Running exactly the same testcase on 1.4.0, I get:

GCC Version: 11.3.0
FLTK Version: 1.4.0
Known monitors: 1
Monitor 1: 11520x2106 (0,0) [Primary Screen]
Workspace: 11520x2106

The monitor count is wrong and the height is off by 54 pixels.

Strangely enough, I occasionally get other weird results in 1.4.0,  like:

Known monitors: 3
Monitor 1: 2560x1440 (5120,0)
Monitor 2: 2560x1440 (0,0)
Monitor 3: 2560x1440 (2560,0) [Primary Screen]
Workspace: 7680x1440

where the monitor count is correct but the resolutions are off.

Am I doing something wrong, or is something wonky with the 1.4.0 screen routines? I've attached the simple testcase that generates these results. Thanks for any insights!

[Manolo]

To start with, it's necessary to know if you run your FLTK apps as X11 clients or as Wayland clients.

To determine that, have a terminal window open and type

     xwininfo <return>

in it, then click with the mouse

on a window of your FLTK app.

If the terminal spits some X11-related text ---> your app is an X11 client

If nothing happens in the terminal window ----> yoiur app is a Wayland client.

 

[Manolo]

A major problem in your testcase.cpp is that the 5th argument of the call to Fl::screen_work_area()

is set to 1, 2, 3 when it should be 0, 1, 2 .

Please, change that and compare what you get with the corrected  testcase.cpp and with test/fullscreen

app that gives in its bottom panel the sizes of all screens of of the work areas of each screen.

Also, what do you get with the "System Settings" application in its "Display Configuration" item?

Please, report the Resolution and Scale values shown there for each of your 3 screens.

[Tigercat]

Good catch on the index. I've fixed the testcase and now display the indexes starting from 0 similar to the fullscreen test code. The updated testcase is attached.

This is a screenshot of my KDE Display Configuration page:

Here's what I get when I run three different versions of test/fullscreen:

From left to right, the first window shows the output from the fullscreen test code  in FLTK 1.3.6. (Gentoo doesn't install the "config.h" file with the library so I commented that include out, hence the "This requires GL" message. Since FLTK 1.3 doesn't scale, this window is also smaller at 100% resolution on the HDPI monitors.)

The second "FLTK<2>" window uses a local git fetch of FLTK with the following message at the top of "git log":

commit 85af0036f9fc733b2e8ad3ae62fd00bc783db738 (HEAD -> master, origin/master,
origin/HEAD)
Author: Albrecht Schlosser <scrub email addr>
Date:   Sat Nov 12 20:14:44 2022 +0100
  Reformat Cairo support Fl_Cairo.cxx for CMP compliance
  Only formatting, no code changes.

So this local git fetch is from a few weeks ago. (I have a few different projects using FLTK that I sporadically update.)

The last window "FLTK<3>" is test/fullscreen from my latest FLTK fetch, with the following git log:

commit bcb739f17f2036ce30ed5cd58627841b59190ea3 (HEAD -> master, origin/master,
origin/HEAD)
Author: Albrecht Schlosser <scrub email addr>
Date:   Sat Nov 26 21:59:03 2022 +0100
   Update dependencies

My default KDE scaling is 150%, and both of these 1.4.0 windows pick that up and scale appropriately. (Curiously enough, one of my FLTK projects stopped automatically scaling with 1.4.0 a few weeks ago; I'm still trying to sort that out as well.)

As you can see, sometime in the last few weeks the FLTK 1.4 code went from reporting three screens to one screen. In both cases the FLTK 1.4 code also displays incorrect monitor resolutions. I believe the FLTK 1.4 code used to match the FLTK 1.3.6 code not that long ago, but I only recently noticed this regression. The test/fullscreen output matches the output from my testcase code.

My WM is KDE running on Xorg, not Wayland. (xwininfo, xdpyinfo etc all confirm):

$ xdpyinfo
name of display:    :0
version number:    11.0
vendor string:    The X.Org Foundation
vendor release number:    12101004
X.Org version: 21.1.4
etc. etc.

Unless you have any quick idea of what's going on, I can try to git-bisect the issue back to where it began.

Thanks!

[Tigercat]

Edit: in my last post I wrote FLTK 1.3.6; that should be FLTK 1.3.5 (the current Gentoo library version).

[Ian MacArthur]

On Tuesday, 29 November 2022 at 07:22:02 UTC Tigercat wrote:

Unless you have any quick idea of what's going on, I can try to git-bisect the issue back to where it began.

If I were to guess (and it is only guess) then I'd suggest that this is some Wayland vs X11 issue. A way to try this would be to explicitly set "OPTION_USE_WAYLAND=NO" (for a cmake build) or "--disable-wayland" for a configure build and then see if the problem disappears. That would then force the build to be X11 only at compile, as it was in the "legacy" builds, rather than having the option set at runtime.

Or, could try setting the FLTK environment variable FLTK_BACKEND (though TBH I can't remember the valid values...) or perhaps even just try setting WAYLAND_DISPLAY  to something invalid... (like "none") for your existing build.

Actually, that's a thought - what does your system report WAYLAND_DISPLAY as?

 

[Ian MacArthur]

On Tuesday, 29 November 2022 at 09:25:38 UTC Ian wrote:

Or, could try setting the FLTK environment variable FLTK_BACKEND (though TBH I can't remember the valid values...) or perhaps even just try setting WAYLAND_DISPLAY  to something invalid... (like "none") for your existing build.

Actually, that's a thought - what does your system report WAYLAND_DISPLAY as?

OK, apparently the valid values for FLTK_BACKEND are:   FLTK_BACKEND=x11   or  FLTK_BACKEND=wayland

With that case setting - I'm pretty sure it is case sensitive.

[Manolo]

Could you, please, report how is the HAVE_XINERAMA line of the config.h file

used when you built the FLTK <3> app shown above ?

Also detail if you used configure+make or cmake to build that ?

[Manolo]

I believe to have understood what happens and to have fixed it with commit 1b0754c

Please, update to the last git version, repeat the

    autoconf -f

command to update the configure file,

and build the FLTK library again with

    ./configure

    make

Report whether your 3 displays are detected as they used to be.

[Tigercat]

Getting closer. My testcase (and the original codebase) now report:

GCC Version: 11.3.0
FLTK Version: 1.4.0

Known monitors: 3
Monitor 0: 2560x1440 (2560,0) [Primary Screen]

Monitor 1: 2560x1440 (5120,0)
Monitor 2: 2560x1440 (0,0)

Workspace: 7680x1440

So it is picking up the three monitors correctly, and it's identifying the primary screen correctly (the one in the 'middle' of three monitors).

However, the resolution is still off. The monitors are 4K 3840x2160 monitors, but the current fltk (commit 1b0754ce4db888b01b291d64330751fe0a77eafc) has them as 2560x1440.

[Tigercat]

BTW, the xinerama setting in config.h is set:

/*
* HAVE_XINERAMA
*
* Do we have the Xinerama library to support multi-head displays?
*/

#define HAVE_XINERAMA 1

At the moment I'm using configure+make to build in the FLTK tree. My main project uses autotools.

I'm under the impression CMake is the 'future' for FLTK. Would the developers recommend that I migrate the build of FLTK to CMake? As I'm on Gentoo access to build systems is not a problem :-)

[Manolo]

Le mercredi 30 novembre 2022 à 01:38:08 UTC+1, Tigercat a écrit :

Getting closer. My testcase (and the original codebase) now report:

GCC Version: 11.3.0
FLTK Version: 1.4.0

Known monitors: 3
Monitor 0: 2560x1440 (2560,0) [Primary Screen]

Monitor 1: 2560x1440 (5120,0)
Monitor 2: 2560x1440 (0,0)

Workspace: 7680x1440

So it is picking up the three monitors correctly, and it's identifying the primary screen correctly (the one in the 'middle' of three monitors).

However, the resolution is still off. The monitors are 4K 3840x2160 monitors, but the current fltk (commit 1b0754ce4db888b01b291d64330751fe0a77eafc) has them as 2560x1440.

I would say we are good now because what you call resolution is in fact each screen size

in FLTK units. Now, these units change when the screen is scaled: the true screen size in pixels is divided

by the scale factor. You wrote you use 150% as scaling for your screens.

This explains that you get 2560x1440 where you'd expect 3840x2160

because 3840 / 1.5 = 2560.

Scaling is introduced in FLTK 1.4 and absent from FLTK 1.3.5 you're used with.

It allows you to keep your source code unchanged and have your GUI moved to

a high DPI display without becoming too small to be readable.

[Manolo]

Le mercredi 30 novembre 2022 à 01:50:12 UTC+1, Tigercat a écrit :

BTW, the xinerama setting in config.h is set:

/*
* HAVE_XINERAMA
*
* Do we have the Xinerama library to support multi-head displays?
*/

#define HAVE_XINERAMA 1

That was the problem.  HAVE_XINERAMA was 0 in the faulty FLTK <3> situation above.

At the moment I'm using configure+make to build in the FLTK tree. My main project uses autotools.

I'm under the impression CMake is the 'future' for FLTK. Would the developers recommend that I migrate the build of FLTK to CMake? As I'm on Gentoo access to build systems is not a problem :-)

Yes, CMake is expected to progressively supplant configure as  building tool.

But configure remains supported by FLTK.

Building FLTK from source with CMake can be as simple as

cd <FLTK source tree>

mkdir build

cd build

cmake ..

make -j4

and you get libraries in <FLTK source tree>/build/lib/

headers in <FLTK source tree>/FL/ and test apps in <FLTK source tree>/bin/test/

 

[Manolo]

Le mercredi 30 novembre 2022 à 04:17:43 UTC+1, Manolo a écrit :

…  and test apps in <FLTK source tree>/bin/test/

error here, sorry, should have been :

 …  and test apps in <FLTK source tree>/build/bin/test/

and also fluid as <FLTK source tree>/build/bin/fluid

[Ian MacArthur]

This is a somewhat off-topic response to one of the comments below, not the main topic of the post!

On Wednesday, 30 November 2022 at 03:17:43 UTC Manolo wrote:

Le mercredi 30 novembre 2022 à 01:50:12 UTC+1, Tigercat a écrit :

I'm under the impression CMake is the 'future' for FLTK. Would the developers recommend that I migrate the build of FLTK to CMake? As I'm on Gentoo access to build systems is not a problem :-)

 

Yes, CMake is expected to progressively supplant configure as  building tool.

But configure remains supported by FLTK.

Though note that (perhaps as here?) they two build systems may not match exactly at all times as development proceeds, and that *in general* the cmake system is a little more likely to be fully "up to date" at any given point as things evolve.

Also, the cmake system seems to be better at detecting and handling dependencies as files change - the dependency generation in our autoconf setup is not 100% reliable and sometimes misses dependencies that cmake does detect.

On the other hand, the fltk-config that the cmake system generates is sometimes a bit wayward; I've found that it is inclined to miss compiler flags (such as optimizer settings) and sometimes image libs, that the autoconf generated version does seem to handle correctly.

YMMV.

[Tigercat]

Ah, the FLTK screen-size units make sense. Your fix likely explains why the 150% scaling of my app at startup has been restored as well. I'll keep the scaling differences in mind moving forward.

Currently, I have FLTK 1.4.0 embedded in my build tree as a git submodule and have automake configure it by calling FLTKs autoconf setup to build it in-tree. I then access the appropriate paths/flags by calling the in-tree fltk-config. I can also switch to Gentoo's current 'stable' FLTK 1.3.5 version with a --enable-system-fltk configure switch instead; in that case I call the system fltk-config to pick up the right paths/flags for FLTK as the Gentoo devs built and installed it. Eventually once 1.4 is released and Gentoo packages it I'll just drop the in-tree build entirely. Until then I'll just try to stay up-to-date with the configuration changes.

Thanks for the quick fixes!

[Albrecht Schlosser]

On 11/30/22 11:52 Ian MacArthur wrote:

This is a somewhat off-topic response to one of the comments below, not the main topic of the post!

On Wednesday, 30 November 2022 at 03:17:43 UTC Manolo wrote:

Le mercredi 30 novembre 2022 à 01:50:12 UTC+1, Tigercat a écrit :

I'm under the impression CMake is the 'future' for FLTK. Would the developers recommend that I migrate the build of FLTK to CMake? As I'm on Gentoo access to build systems is not a problem :-)

 

Yes, CMake is expected to progressively supplant configure as  building tool.

But configure remains supported by FLTK.

... definitely for FLTK 1.4.0 and very likely for all 1.4.x versions unless we decide otherwise.

Maintaining two entirely different build systems (and keeping them in sync) is something we might not do for all times...

CMake is the build system we *must* maintain because Visual Studio and other IDE's require using CMake to build the project files.

configure/make is ... well, old-fashioned and really difficult to maintain.

Though note that (perhaps as here?) they two build systems may not match exactly at all times as development proceeds, and that *in general* the cmake system is a little more likely to be fully "up to date" at any given point as things evolve.

That is definitely my goal. Or putting it the other way around: in the future the configure/make system *may* lack some new features that will only be available in CMake, and eventually we *may* drop configure/make support or may only fix severe bugs.

Also, the cmake system seems to be better at detecting and handling dependencies as files change - the dependency generation in our autoconf setup is not 100% reliable and sometimes misses dependencies that cmake does detect.

To be precise: the autoconf (configure/make) build system is unreliable in almost 100% because we don't (and we can't!) maintain dependencies for all potential configurations.

There is only one working workaround: if users have the `makedepend` tool installed on their system they can execute `make depend` (note the space) in the FLTK root directory *after* configure/make and later whenever they use `git update` or change FLTK sources or the configuration. This is error prone and I recommend strongly to switch to CMake whenever possible - at least for building the FLTK libs.

On the other hand, the fltk-config that the cmake system generates is sometimes a bit wayward; I've found that it is inclined to miss compiler flags (such as optimizer settings) and sometimes image libs, that the autoconf generated version does seem to handle correctly.

YMMV.

This is true for today but should be fixed before FLTK 1.4.0 is released. I'm aware of this and I *will* do my best to fix this.

My goal here is that CMake will be a fully functional and feature-complete replacement of our configure/make system when FLTK 1.4.0 will be released. In the future CMake should always be the "better" build system, i.e. a functional superset of our configure/make system, and CMake is definitely superior in detecting build dependencies.

[Albrecht Schlosser]

On 11/30/22 01:50 Tigercat wrote:
>
> At the moment I'm using configure+make to build in the FLTK tree. My
> main project uses autotools.
>
> I'm under the impression CMake is the 'future' for FLTK. Would the
> developers recommend that I migrate the build of FLTK to CMake? As I'm
> on Gentoo access to build systems is not a problem :-)

Please see my more detailed reply to Ian's message in this thread.

I would appreciate if you migrated the FLTK build to CMake at least for
testing and give us feedback about issues and problems.

Currently there are still some known issues in the CMake build but these
should be fixed soon. If you don't encounter build problems and plan to
update the FLTK sources from time to time, then the unreliable
dependency detection in the configure/make system might cause you
trouble which you can avoid by using CMake to build FLTK. There's no
problem if you always do a full build with either system.

Once FLTK 1.4.0 is released the CMake build should be the preferred and
superior build system and I would definitely recommend using it to build
FLTK, especially because of the working dependency detection for
incremental builds after source code updates.

[Tigercat]

Works for me. As an old-time Unix guy I use autotools most of the time because I'm usually just targeting Linux/Gnu, but for those times I do cross-platform Windows/Mac/Linux work I also find CMake is usually the best of the (all-problematic) options. I'll switch over and watch for issues.

[Ian MacArthur]

On Wednesday, 30 November 2022 at 16:51:23 UTC Albrecht Schlosser wrote:

On 11/30/22 11:52 Ian MacArthur wrote:

This is a somewhat off-topic response to one of the comments below, not the main topic of the post!

Also, the cmake system seems to be better at detecting and handling dependencies as files change - the dependency generation in our autoconf setup is not 100% reliable and sometimes misses dependencies that cmake does detect.

To be precise: the autoconf (configure/make) build system is unreliable in almost 100% because we don't (and we can't!) maintain dependencies for all potential configurations.

There is only one working workaround: if users have the `makedepend` tool installed on their system they can execute `make depend` (note the space) in the FLTK root directory *after* configure/make and later whenever they use `git update` or change FLTK sources or the configuration. This is error prone and I recommend strongly to switch to CMake whenever possible - at least for building the FLTK libs.

I caution here that "makedpend" doesn't really work either...

It's pretty old, from early X11 / Athena stuff I think, and it doesn't seem to cope well with modern code, or at least with code that has conditional compilation and such (like, say, fltk...)

I'm not *sure* about the Linux builds of fltk, but for sure the dependencies that "makedepend" generates on mingw systems is awry. (I'm pretty sure it's awry under Linux too, FWIW.) 

I have a hack that generates dependencies using gcc's own checks, so represents the dependencies that the compiler actually wants (accounting for conditional code paths and etc...) and that finds *a lot* more things than makedepend does. (But that approach is not portable since it doesn't work with cl; it does work with llvm/clang and icc though, FWIW, and I have a wrapper I use sometimes to get deps out of cl, reformatted into gnu make format, but it's awkward to use so I don't think it is an option for wider use...)

Generally, cmake does a better job of the deps.

Or do a clean build, so the deps don't matter!

[Greg Ercolano]

On 11/30/22 09:21, Tigercat wrote:

Works for me. As an old-time Unix guy I use autotools most of the time because I'm usually just targeting Linux/Gnu, but for those times I do cross-platform Windows/Mac/Linux work I also find CMake is usually the best of the (all-problematic) options. I'll switch over and watch for issues.

    The biggest thing cmake gave us was Windows support for Visual Studio.

    We had to manually maintain separate IDE files for different VS versions
    which was a giant pain in the but, and made for unnecessarily large tar files
    for all those separate project files and junk. With cmake, it generates those
    'on the fly' so we don't have to include them in the tar files.

    I'm sure Albrecht, who's our cmake wizard, would also chime in about many
    other benfits, not the least of which localizes each build in a separate directory,
    making it easier to build the same source code (on a file server) built across
    platforms without crosstalk in the source directories.

    I get the impression cmake is a bit of a large undertaking to learn fully,
    but honestly so is automake/configure. I never really understood the
    underbelly of either one, so I tend to hand craft Makefiles myself
    and avoid IDEs so my apps and FLTK can be build via scripts. At least
    cmake allows that to be possible without the handcrafting, which is fine with me..!

[Ian MacArthur]

On Wednesday, 30 November 2022 at 17:43:32 UTC Erco wrote:

    I get the impression cmake is a bit of a large undertaking to learn fully,

    but honestly so is automake/configure. I never really understood the
    underbelly of either one, so I tend to hand craft Makefiles myself
    and avoid IDEs so my apps and FLTK can be build via scripts. At least
    cmake allows that to be possible without the handcrafting, which is fine with me..!

Yup, I'm with that - judicious use of Makefiles and fltk-config goes a long way...

(So long as fltk-config works!)