Am Mon, 20 Oct 2008 12:20:29 +0100 schrieb Jeremy Henty <onepoint@starurchin.org>:

I also run dillo2 on GNU/Linux and modular X.org and I see nothing like this. Do you see these problems all all the time? Can you tell us more about your setup (Linux distro, X.org version, window manager etc.)? Without more information it's going to be hard to help.

Well, this is happening with plain startx /usr/bin/dillo -- :1 So, perhaps we can rule out the window manager;-) -- it would be fluxbox, btw. xorg stuff is _very_ recent, as this is SourceMage GNU/Linux with test grimoire, rolling release. xorg-server 1.5.2 and associated versions... And yes, it is happening all the time. The test apps in FLTK2 build directory work fine, though. Alrighty then, Thomas.

Am Mon, 20 Oct 2008 16:23:07 +0200 schrieb Johannes Hofmann <Johannes.Hofmann@gmx.de>:

You've built FLTK2 manually then, right?

Yes and no. The version dillo is using is built by the distribution scripts. This being a source-based distro sort of means that still, I have it built locally... But for the FLTK2 tests, I indeed built it manually and ran them in the build directory -- but that has not been installed.

Which snapshot are you using?

The newest I know, fltk-2.0.x-r6403 (I included this info in my bug submission, but had to delete stuff because of text size limit...).

Any special configure options for FLTK2?

Well, the distro build is tunable and included these: --enable-shared --enable-threads --enable-xdbe --enable-xinerama --enable-xft --enable-cairo --enable-png --enable-zlib --enable-gl

Is it possible that there is another FLTK2 installation on your system (e.g. one in /usr/ and one in /usr/local)?

No, in the system there is only the one installed by the distro scripts.

Does changing the buffered_drawing option in dillorc to 0 or 2 make a difference?

Hm... the FLTK2 test for the buffering worked fine (in case we are talking about the same)... testing this now with dillo. It makes a difference, at least. No setting fixes the whole experience, but with 2, the refresh on uncovering the window works and the main body seems to be stable. What remains is the clutter from text lines over the menu bar and status bar. When scrolling down, text fragments appear and stay at the top, when scrolling up, text fragments appear and stay at the bottom. Alrighty then, Thomas.

Am Mon, 20 Oct 2008 16:59:34 +0200 schrieb Johannes Hofmann <Johannes.Hofmann@gmx.de>:

With these options I can reproduce the problem. I guess --enable-cairo is the problematic one. Can you try to compile dillo with a manually compiled fltk2 without --enable-cairo?

Nothing easier than that with the source-based distro;-) I have a system fltk2 lib now without cairo and now dillo2 works nicely! So cairo in FLTK2 is buggy? Or its usage in dillo... but I suppose that FLTK2 should abstract that away. This could meant that we can close the bug; but the information about the cairo issue should be FAQed somewhere -- ideally, of course, solved upstream. Btw: FLTK2 not having a stable release is a bit of a problem with replacing the old "stable" dillo with dillo2... I hope that situation is resolved soon. Well, and the missing feature of frames; whatever one's opinion, the dillo patch that enabled this is commonplace and this missing is a de facto regression... But I'm really delighted to see that dillo is still alive, really. I dream of a lean, stable browser that can do https and CSS. Perhaps that dream comes true, finally. Alrighty then, Thomas.

Johannes wrote:

Yes, we should mention that somewhere. FAQ or README?

dillo's configure.in could grep for cairo in LIBFLTK_LIBS, right? In the meantime, I just stuck warnings on download.html and cvs.html. Guess I'll add something to the FAQ as well...