FLTK flickering on X11 depending on resolution

[Dibo]

Hi,

In my workstation I have 3 different displays (I work only on one at the time). First is laptop display 1920x1080 60Hz, second is 4k external monitor with 150% scale and 120Hz (HDMI). And third one is external monitor 1920x1080 and 144Hz (HDMI).

On laptop display and 4k 120Hz monitor I get weird flickering. Only on monitor with 144Hz it is fine. Same result with Fl_Window and Fl_Double_Window. See attached videos.

Tested also Qt demo which has similar backend and here it is fine on all displays.

Any idea?

I'm using FLTK 1.4.5.

CachyOS KDE Wayland. AMD Ryzen 7 8840U w/ Radeon 780M Graphics

FLTK build with flags:

./configure --enable-xft --enable-threads --enable-localjpeg --enable-localpng --enable-localzlib --enable-use_std

and then just:

make

Project build with targets:

target_link_libraries(testFLTK PRIVATE
    fltk
    fltk_images
    fltk_forms
    fltk_jpeg
    fltk_png
    fltk_z
    Xrender
    Xcursor
    Xfixes
    Xft
    fontconfig
    Xinerama
    pthread
    m
    X11
)

[Ian MacArthur]

On Thursday, 13 August 2026 at 20:00:37 UTC+1 k.dib... wrote:

Hi,

In my workstation I have 3 different displays (I work only on one at the time). First is laptop display 1920x1080 60Hz, second is 4k external monitor with 150% scale and 120Hz (HDMI). And third one is external monitor 1920x1080 and 144Hz (HDMI).

On laptop display and 4k 120Hz monitor I get weird flickering. Only on monitor with 144Hz it is fine. Same result with Fl_Window and Fl_Double_Window. See attached videos.

Tested also Qt demo which has similar backend and here it is fine on all displays.

Any idea?

Not as such, other than to say I have a few monitors hanging off this laptop, and I'm not seeing any flickering.

Generally it mostly seems to work. That said, I don't have any monitor that runs as fast as 144Hz...

This laptop has 2 discrete outputs (one HDMI, one mini-DP) - for its predecessor I had one HDMI and another monitor on a USB-C port. That one was always a bit dodgy, the USB-C display was "unreliable", but in all cases, not just FLTK!

 

I'm using FLTK 1.4.5.

A question: If you are using FLTK 1.4.5, and it looks like you are using cmake for your project, why did you build FLTK using the legacy configure script, rather than using cmake to build FLTK too?

For FLTK 1.4.x the cmake configuration is probably the "better" option.

Can you tell whether your app is actually running as X11 or as Wayland?

I wonder whether the build has perhaps produced an X11-only version of the FLTK lib and it's making a poor stab at running under Wayland on your machine.

A FLTK 1.4 build ought to have a "universal" back-end to select between Wayland and X11 at runtime, but perhaps that's not working in your build?

If you do a FLTK build with cmake, what back-end does the build report?

[Manolo]

Hi,

As Ian already suggested, I would recommend to build FLTK 1.4.5 as a Wayland client which should hopefully remove any flickering. Your message suggests you've obtained libfltk as an X11 client. The reason is probably that some packages necessary at FLTK build time are not installed in your system. Please, refer to section 3. of file README.Wayland.txt of the FLTK source tree which lists what packages are necessary. You'll have to extrapolate package names for the pacman system. I have built successfully FLTK for ArchLinux, so you should be successfull with CachyOS too.

[Dibo]

Indeed seems that I have build with X11 only (BTW: finally tried cmake as Ian suggested):

-- Use Wayland              No (X11 is used)
-- All drawing uses Cairo   No
-- Use Pango                No
-- Use Xft                  Yes
-- Fl_Cairo_Window support  No
-- Use std::                Yes

Some time ago I tried build with wayland (I was missing wayland-protocols package and that is a reason why ./configure make build for X11 only) because I wanted to enable antyaliasing for rounded buttons. App looked pretty sweet but when I saw that it bloat librarys dependencies (cairo, pango and a lot more) then I removed wayland-protocols package to fallback to lightweight version. I also wasn't sure if my app require wayland on end user (I wouldn't like to make separated builds for X11 and wayland) but if you say that it is runtime switch then I give it a try. 

Now I have:

-- Use Wayland              Yes (can also run as X11 client)
-- All drawing uses Cairo   Yes
-- Use Pango                Yes
-- Fl_Cairo_Window support  No
-- Use std::                Yes

And everything is smooth, no flickering at all and even rendering is much more sharper, seems like on 4k, X11 used some kind of rescaling instead of native drawing. But there are downsides - executable size grows up from 650kb to 1.1MB and memory usage from 3.3MB on X11 to 19.3MB on wayland build. That is still peanut in nowadays with all electron alike apps and still less than Qt simple app. What worries me more is backend libs dependencies:

On X11 it is only basic what all linux distros have:

ldd ./testFLTK
        linux-vdso.so.1 (0x00007f77028a2000)
        libXrender.so.1 => /usr/lib/libXrender.so.1 (0x00007f77027b3000)
        libXcursor.so.1 => /usr/lib/libXcursor.so.1 (0x00007f77027a5000)
        libXfixes.so.3 => /usr/lib/libXfixes.so.3 (0x00007f770279d000)
        libXft.so.2 => /usr/lib/libXft.so.2 (0x00007f770277c000)
        libfontconfig.so.1 => /usr/lib/libfontconfig.so.1 (0x00007f77026f5000)
        libXinerama.so.1 => /usr/lib/libXinerama.so.1 (0x00007f77026ee000)
        libX11.so.6 => /usr/lib/libX11.so.6 (0x00007f7702582000)
        libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x00007f7702200000)
        libm.so.6 => /usr/lib/libm.so.6 (0x00007f77020f9000)
        libgcc_s.so.1 => /usr/lib/libgcc_s.so.1 (0x00007f770254d000)
        libc.so.6 => /usr/lib/libc.so.6 (0x00007f7701e00000)
        libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0x00007f7701ce1000)
        libexpat.so.1 => /usr/lib/libexpat.so.1 (0x00007f77020c2000)
        libXext.so.6 => /usr/lib/libXext.so.6 (0x00007f7702531000)
        libxcb.so.1 => /usr/lib/libxcb.so.1 (0x00007f7702095000)
        /lib64/ld-linux-x86-64.so.2 => /usr/lib64/ld-linux-x86-64.so.2 (0x00007f77028a4000)
        libz.so.1 => /usr/lib/libz.so.1 (0x00007f7702059000)
        libbz2.so.1.0 => /usr/lib/libbz2.so.1.0 (0x00007f7702044000)
        libpng16.so.16 => /usr/lib/libpng16.so.16 (0x00007f7701c88000)
        libbrotlidec.so.1 => /usr/lib/libbrotlidec.so.1 (0x00007f7701c78000)
        libXau.so.6 => /usr/lib/libXau.so.6 (0x00007f7702529000)
        libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0x00007f7701c70000)
        libbrotlicommon.so.1 => /usr/lib/libbrotlicommon.so.1 (0x00007f7701c4d000)

With wayland it is a bit bloated:

❯ ldd ./testFLTK
        linux-vdso.so.1 (0x00007fcf7e85d000)
        libXinerama.so.1 => /usr/lib/libXinerama.so.1 (0x00007fcf7e70e000)
        libXfixes.so.3 => /usr/lib/libXfixes.so.3 (0x00007fcf7e706000)
        libXcursor.so.1 => /usr/lib/libXcursor.so.1 (0x00007fcf7e6f8000)
        libpangoxft-1.0.so.0 => /usr/lib/libpangoxft-1.0.so.0 (0x00007fcf7e6ec000)
        libpangoft2-1.0.so.0 => /usr/lib/libpangoft2-1.0.so.0 (0x00007fcf7e6cc000)
        libpango-1.0.so.0 => /usr/lib/libpango-1.0.so.0 (0x00007fcf7e64b000)
        libXft.so.2 => /usr/lib/libXft.so.2 (0x00007fcf7e62a000)
        libfontconfig.so.1 => /usr/lib/libfontconfig.so.1 (0x00007fcf7e5a3000)
        libharfbuzz.so.0 => /usr/lib/libharfbuzz.so.0 (0x00007fcf7e42f000)
        libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0x00007fcf7e310000)
        libgobject-2.0.so.0 => /usr/lib/libgobject-2.0.so.0 (0x00007fcf7e29b000)
        libglib-2.0.so.0 => /usr/lib/libglib-2.0.so.0 (0x00007fcf7e111000)
        libpangocairo-1.0.so.0 => /usr/lib/libpangocairo-1.0.so.0 (0x00007fcf7e0fd000)
        libcairo.so.2 => /usr/lib/libcairo.so.2 (0x00007fcf7df64000)
        libX11.so.6 => /usr/lib/libX11.so.6 (0x00007fcf7ddf8000)
        libXrender.so.1 => /usr/lib/libXrender.so.1 (0x00007fcf7ddea000)
        libwayland-cursor.so.0 => /usr/lib/libwayland-cursor.so.0 (0x00007fcf7dde1000)
        libwayland-client.so.0 => /usr/lib/libwayland-client.so.0 (0x00007fcf7ddce000)
        libxkbcommon.so.0 => /usr/lib/libxkbcommon.so.0 (0x00007fcf7dd60000)
        libdbus-1.so.3 => /usr/lib/libdbus-1.so.3 (0x00007fcf7dd05000)
        libdecor-0.so.0 => /usr/lib/libdecor-0.so.0 (0x00007fcf7dcfb000)
        libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x00007fcf7d800000)
        libm.so.6 => /usr/lib/libm.so.6 (0x00007fcf7dbf4000)
        libgcc_s.so.1 => /usr/lib/libgcc_s.so.1 (0x00007fcf7dbbd000)
        libc.so.6 => /usr/lib/libc.so.6 (0x00007fcf7d400000)
        libXext.so.6 => /usr/lib/libXext.so.6 (0x00007fcf7dba3000)
        libgio-2.0.so.0 => /usr/lib/libgio-2.0.so.0 (0x00007fcf7d000000)
        libfribidi.so.0 => /usr/lib/libfribidi.so.0 (0x00007fcf7db80000)
        libthai.so.0 => /usr/lib/libthai.so.0 (0x00007fcf7db71000)
        libexpat.so.1 => /usr/lib/libexpat.so.1 (0x00007fcf7db3a000)
        libgraphite2.so.3 => /usr/lib/libgraphite2.so.3 (0x00007fcf7d7dd000)
        libz.so.1 => /usr/lib/libz.so.1 (0x00007fcf7d7a1000)
        libbz2.so.1.0 => /usr/lib/libbz2.so.1.0 (0x00007fcf7d78c000)
        libpng16.so.16 => /usr/lib/libpng16.so.16 (0x00007fcf7d733000)
        libbrotlidec.so.1 => /usr/lib/libbrotlidec.so.1 (0x00007fcf7db28000)
        libffi.so.8 => /usr/lib/libffi.so.8 (0x00007fcf7d724000)
        libpcre2-8.so.0 => /usr/lib/libpcre2-8.so.0 (0x00007fcf7d659000)
        libxcb.so.1 => /usr/lib/libxcb.so.1 (0x00007fcf7d3d3000)
        libxcb-render.so.0 => /usr/lib/libxcb-render.so.0 (0x00007fcf7d647000)
        libxcb-shm.so.0 => /usr/lib/libxcb-shm.so.0 (0x00007fcf7d642000)
        libpixman-1.so.0 => /usr/lib/libpixman-1.so.0 (0x00007fcf7d240000)
        libsystemd.so.0 => /usr/lib/libsystemd.so.0 (0x00007fcf7ceb9000)
        /lib64/ld-linux-x86-64.so.2 => /usr/lib64/ld-linux-x86-64.so.2 (0x00007fcf7e85f000)
        libgmodule-2.0.so.0 => /usr/lib/libgmodule-2.0.so.0 (0x00007fcf7d239000)
        libmount.so.1 => /usr/lib/libmount.so.1 (0x00007fcf7ce5d000)
        libdatrie.so.1 => /usr/lib/libdatrie.so.1 (0x00007fcf7d22e000)
        libbrotlicommon.so.1 => /usr/lib/libbrotlicommon.so.1 (0x00007fcf7ce3a000)
        libXau.so.6 => /usr/lib/libXau.so.6 (0x00007fcf7d228000)
        libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0x00007fcf7d220000)
        libblkid.so.1 => /usr/lib/libblkid.so.1 (0x00007fcf7cdfa000)

At least I don't see any GTK or Qt related dependencies, that is a big relief. Because you know... I would like to keep my app running "out of the box"

[Greg Ercolano]

On 8/14/26 08:29, Dibo wrote:

With wayland it is a bit bloated [larger list of runtime libs]

    From what I've seen during Wayland development, very necessary.
    Wayland itself does very little, making it lightweight, but putting the burden of e.g. fonts, line and shape drawing, etc. on the applications, and this is the cost; lots of runtime modules being pulled in.

    The good news is, technically, we should be getting better/faster behavior out of Wayland; antialiasing from cairo, better font rendering and calculations (freetype/pango). Things were cleaned up and old ways abandoned completely for newly designed behavior to keep up with modern graphics.

    But if you're looking for truly light weight, perhaps retreating to Xwindows (still around, I'm using an Xorg server on Ubuntu, mainly for screen sharing, but also to allow apps to run on one machine, and display on another).

    If I was making an app that needed to be light weight, like for a kiosk or some such dedicated application, I'd probably be considering a "windowmanager-less" X11, vs. wayland with a light weight "compositor" (in place of a window manager) to handle the miniumum requirement to run an application "windowmanager-less".

[Manolo]

On 8/14/26 08:29, Dibo wrote:

With wayland it is a bit bloated [larger list of runtime libs]

This long list of runtime libs should not, I believe, be seen as a weight FLTK carries to use Wayland. Most, if not all, of these libraries are loaded into memory when the desktop (Plasma it seems in your case) starts. FLTK just points into these parts of the memory, adding to the memory cost its own source code, but sharing the already paid cost of all listed libraries.

            And everything is smooth, no flickering at all and even rendering is much more sharper, seems like on 4k.

That's very good news. Wayland was conceived to remove any flickering by design.

               But there are downsides - executable size grows up from 650kb to 1.1MB and memory usage 

               from 3.3MB on X11 to 19.3MB on wayland build.

One way to reduce the executable size would be to build FLTK for Wayland only, if it can be ensured the app will be used only with Wayland-based desktops (e.g., Gnome, Plasma).

[Dibo]

Yes, a lot of issues which I have to figure out if I want to stick to this build configuration. For example, I know that I want to make own scheme and modify box drawings to have nice roundings so it doesn't look like windows 98 app. To do so I need antyaliasing anyway and I don't know what deploy obstacles waiting for me on Windows OS. To be honest I know nothing about cairo and pango on windows and didn't read yet if GDI+ solve this issues. Anyway I'm a big fan of "self drawing" frameworks and I'm glad that I found FLTK, good work guys. I'm senior Delphi (in fact Free Pascal) developer and here we have similar frameworks like fpGUI or MSEGUI. Recently I also started PasFLTK bindings for FLTK (https://github.com/dibok/PasFLTK) where I made "Fusion Style" because fl_get_system_colors() doesn't work on modern KDE / GNOME UI, that is another issue which I have no time to figure out and solved on my way (reading colors from GTK2 scheme file). If we are in this topic, does anyone know if FLTK 1.5 fix that? Here is example of FLTK Fusion Style on KDE Dark and Windows Dark: