| Title | Prepare Dillo for FLTK 1.4 |
|---|---|
| Author | rodarima |
| Created | Thu, 15 Aug 2024 17:45:38 +0000 |
| State | open |
We should prepare Dillo to be compatible with FLTK 1.4, as currently the configure prevents building with other than FLTK 1.3.
There may be some other changes to do with the transition.
FLTK 1.4rc1 released: https://www.fltk.org/newsgroups.php?s22210+gfltk.coredev+v22223
One of the main changes with FLTK 1.4 is that they switched the units to "scale units", which are DPI independent. This will cause problems with images and text that is currently rendered to be shown at an specific size.
We probably will need to adjust the rendering of elements to take into the account the DPI, so they are properly rendered on the screen. Similarly, icons will need to have higher resolutions, so we can properly scale them on high DPI screens.
So far FLTK 1.4 causes gliches when scrolling, so it will remain not compatible until we can fix them:
FLTK 1.4.0rc2 has been released: https://www.fltk.org/articles.php?L1949
I don't see any scrolling glitches as you mentioned above, so hopefully thats fixed now.
I don't see any scrolling glitches as you mentioned above, so hopefully thats fixed now.
These problems are likely in Dillo not FLTK. The FLTK new commits don't change any DPI code that I can see. They are still present for me on 1.4.0rc2.
What is your screen DPI? Are you on Xorg or Wayland? If on Xorg:
$ xdpyinfo | grep -B2 resolution
Also, how did you built dillo with FLTK 1.4? Can you attach the config.log and:
$ ldd src/dillo
It's Xorg @ 96dpi.
I set configure.ac to:
AC_PATH_PROG(FLTK_CONFIG,fltk-config)
AC_MSG_CHECKING([FLTK 1.4])
fltk_version="$FLTK_CONFIG --version 2>/dev/null"
case $fltk_version in
1.4.*) AC_MSG_RESULT(yes)
LIBFLTK_CXXFLAGS=$FLTK_CONFIG --cxxflags
LIBFLTK_CFLAGS=$FLTK_CONFIG --cflags
LIBFLTK_LIBS=$FLTK_CONFIG --ldflags;;
Then removed the original FLTK package, built the new 1.4.0rc2 from source, and installed:
$ fltk-config --version 1.4.0
Then built dillo with the new version.
I sent you the config.log and the ldd output.
It's Xorg @ 96dpi.
I don't think you will see it on 96dpi. You need a DPI value larger than 96 (but not a multiple), so it triggers the rounding problem. My screen is 101dpi which seems to be very problematic.
You may be able to fake a 101dpi and reproduce it with:
$ FLTK_SCALING_FACTOR=1.0539418854166667 src/dillo
I can also try with another 96dpi screen and see if it goes away on my end (probably).
Ok, I start to see some glitching when doing that, and when changing the dpi higher than 96 with xrandr.
For info - I just built dillo-3.1.0 against fltk-1.4.0rc3 wayland only and things seem to work
FLTK 1.4.1 was released a while ago, and the changelog indicates that this issue might be fixed, but unfortunately there is still some of this glitching happening in Dillo with it.
FLTK 1.4.1 was released a while ago, and the changelog indicates that this issue might be fixed, but unfortunately there is still some of this glitching happening in Dillo with it.
This issue is here to act as a meta-issue, so I can cross-link all other fixes required for FLTK 1.4. There are several issues with FLTK 1.4 which you can find in the issue tracker searching for "FLTK" (I should add a new label).
Until all of them are solved and I have checked that there is no big penalty in performance, I will not consider supporting FLTK 1.4 officially. Some issues may require large changes on Dillo, so I would not expect this to happen any time soon.
If you are refering to this:
Fix graphical glitches on 101 DPI screen
This doesn't solve the issue on Dillo rendering, but it "fixes" a issue on a FLTK test program.
I have multiple patches to mitigate this issue, none good enough. There is something wrong on the FLTK side, and until I don't find the proper solution, it will remain broken.
There are other issues that are not so evident which would need to be solved too. So it is safer to keep Dillo clearly broken, so we don't end up with distributions shipping with FLTK 1.4 and a crappy patch to make it apparently work.
One way in which you can help is by testing future patches on your hardware, so we can determine it is fixed on a broad variety of screen resolutions. In the meanwhile, we will have to wait.
Until all of them are solved and I have checked that there is no big penalty in performance, I will not consider supporting FLTK 1.4 officially. Some issues may require large changes on Dillo, so I would not expect this to happen any time soon.
Makes sense. Hopefully distros won't be too quick to phase-out FLTK 1.3.X versions for now.
If you are refering to this:
Fix graphical glitches on 101 DPI screen
This doesn't solve the issue on Dillo rendering, but it "fixes" a issue on a FLTK test program.
Right, that's the one that got my attention...
So it is safer to keep Dillo clearly broken, so we don't end up with distributions shipping with FLTK 1.4 and a crappy patch to make it apparently work.
Given that it is taking me a while to fix this, I think it would be more useful to output the current patch under a --enable-experimental-fltk-1.4 configure flag (or similar), so users have to manually activate it. Hopefully this will stop distributions from enabling it by default, and give users the chance to test it and potentially contribute towards a fix.
Related: https://github.com/dillo-browser/dillo/issues/258