Hello there!I'm an fltk-rs user, but the problem I've encountered is appearing in other FLTK applications as well. Consider the following comparison of focus boxes on my machine (left) and on a virtual machine (right). Both are the same systems, Fedora 34.
On Fri, 10 Sep 2021, 16:57 paveloom wrote:
Hello there!
I'm an fltk-rs user, but the problem I've encountered is appearing in other FLTK applications as well. Consider the following comparison of focus boxes on my machine (left) and on a virtual machine (right). Both are the same systems, Fedora 34.
There's a rendering bug in some X11 drivers that can look like that, so I'd guess that's what you are hitting.
It's not really a fltk thing and I don't think we know how to work around it.
I assume it's fine when you try your app on a different machine?
On 9/10/21 9:35 AM, imm wrote:
On Fri, 10 Sep 2021, 16:57 paveloom wrote:
Hello there!
I'm an fltk-rs user, but the problem I've encountered is appearing in other FLTK applications as well. Consider the following comparison of focus boxes on my machine (left) and on a virtual machine (right). Both are the same systems, Fedora 34.
There's a rendering bug in some X11 drivers that can look like that, so I'd guess that's what you are hitting.
It's not really a fltk thing and I don't think we know how to work around it.
On 9/10/21 10:04 AM, Albrecht Schlosser wrote:
There's a possible workaround if you set the line width to 1 rather than 0 (the default). The drawback is that setting the width to 1 slows things down and that's why it's not (yet?) done.
Maybe we should set the line width to 1 explicitly for the focus box which shouldn't harm much (in terms of drawing speed) but there are other visible effects (missing pixels in rectangles) as well.
On 9/10/21 6:35 PM imm wrote:
On Fri, 10 Sep 2021, 16:57 paveloom wrote:
Hello there!
I'm an fltk-rs user, but the problem I've encountered is appearing in other FLTK applications as well. Consider the following comparison of focus boxes on my machine (left) and on a virtual machine (right). Both are the same systems, Fedora 34.
There's a rendering bug in some X11 drivers that can look like that, so I'd guess that's what you are hitting.
Yes, see issue #156: https://github.com/fltk/fltk/issues/156
To answer that specific question (what's the problem), I believe
it's the X11 default "modesetting" driver.
Try running 'lsmod' and see if you see 'modesetting' in the report;
if so, that's likely the cause. Or grep your Xorg.0.log for "modesetting".
Pretty sure the presence and active use of that driver is the cause.
If you install the actual manufacturer graphics drivers, that 'modesetting'
default driver should go away, and with it, the problem should go too.
For a workaround in FLTK, see the other replies in this thread which
would set the linewidth to 1 when drawing the focus box.
The github issue Albrecht mentioned refers back to an older, long thread
that goes into the details of using linewidth = 1 and speed issues it can cause
if used across the board, which is why we continue to use linewidth=0 as the default:
https://groups.google.com/g/fltkcoredev/c/K8Pc0O-dCs0/m/CZ5rMRhmCQAJ
But I'd agree we could/should modify just the focus box drawing code
to set the linewidth to 1, just for portability, as I think Manolo had recommended
in the github thread. I wouldn't expect any significant slowdown from just focus box drawing.
Okay, so, on Wayland, this is a bug in the X Server's Glamor layer. Here's the tracking issue. As a workaround, one can disable the Glamor acceleration in XWayland by setting `XWAYLAND_NO_GLAMOR=1` globally. However, that also means the rendering of all X11 applications will be slower.
--
You received this message because you are subscribed to the Google Groups "fltk.general" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fltkgeneral...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/fltkgeneral/b6e2e768-4dbc-4d71-8c60-82eca8c62a2an%40googlegroups.com.