Focus boxes are broken on my machine

[paveloom]

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.

So, somehow the focus boxes are not displaying correctly on my machine. Any ideas what's the problem here can be?

[imm]

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?

--
Ian
From my Fairphone FP3
 

[Albrecht Schlosser]

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

It's not really a fltk thing and I don't think we know how to work around it.

It's {very likely | definitely} an X11 driver thing (bug). 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.

I assume it's fine when you try your app on a different machine?

Unless that other machine has the same driver bug. :-(

[Greg Ercolano]

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.

    Yep, confirmed that a few times, it's a buggy default X11 driver.

    The proper fix is to install the right drivers for the graphics card
    so it doesn't use the default driver. I remember solving that one by
    installing the intel graphics drivers from the distro, as I think intel
    no longer supplies the drivers directly, you have to go through the
    distro packaging.

It's not really a fltk thing and I don't think we know how to work around it.

    The workaround is to set the line width to 1 instead of 0 for drawing the focus box.

    While 0 is the right thing, it has a buggy driver implementation.
    (This can be proven by running the X11 line drawing test code, which is pure X11,
    and seeing the same issue, i.e. ruling out FLTK)

[Greg Ercolano]

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.

    Yes, that's what I remember too (setting linewidth to 1).

    IIRC the focus box is "special" in that it uses the dotted line pattern for lines,
    and for whatever reason that combined with 0 width line causes a problem
    with the pattern generation.

    The zero width also creates holes in the corners of boxes. Probably the issue
    is related somehow, as it's probably miscalculating the ends of line segments
    causing dropouts and unintended connections. The apparent randomness in the
    output makes me think it's some kind of uninitialized memory in the driver code.

[Albrecht Schlosser]

On 9/10/21 7:04 PM Albrecht Schlosser wrote:

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

FTR: The patch in https://github.com/fltk/fltk/files/5745668/focus_rect_xlib.diff.txt should fix the issue. However, this is not a 100% correct fix because the line width gets unconditionally (re)set to 0 after drawing the focus box.

@OP (paveloom): can you please test and report if the fix above works for you?

Other than that, Greg's advice to install another driver is worth a try as well if it is feasible for you...

[Greg Ercolano]

On 9/10/21 8:57 AM, paveloom wrote:

> So, somehow the focus boxes are not displaying correctly on my machine.
> Any ideas what's the problem here can be?

    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.

[Pavel Sobolev]

Thank you all.

Here are some nuances I have with suggested solutions:

1.     Since I'm using Rust bindings, I can't apply the suggested patch. All I have on the user side is the set_line_style method, but focus boxes ignore it;
2.     Since I'm on Fedora 34, I can't find a way to upgrade my Intel graphics driver. It supposedly comes preinstalled with the system (in parts) and is already updated to the latest version;
3.     I don't see `modesetting` in the `lsmod`'s output. But since there are other reports that this happens when this module is used, I still poked around the Internet and found a solution:

Putting

```

Section "OutputClass"
        Identifier "Intel"
        MatchDriver "i915"
        Driver "intel"
EndSection

```

in `/etc/X11/xorg.conf.d/10-intel.conf` solves the problem on X11. Still searching for how to fix it on Wayland.

[Ian MacArthur]

Cool, that’ll be useful to know.
I assume that setting the driver explicitly like this is, broadly speaking, analogous to Greg’s suggestion of installing the alternate driver...?

> Still searching for how to fix it on Wayland.

I have nothing useful here - I *assume* that down in the lowest level the X11 and Wayland code uses the same drivers, but I have no clue how to tell Wayland which driver you want it to use!


I suppose uninstalling the “wrong” driver might be a way of forcing the issue...?
(Since the “right” driver seems to be available anyway, and would presumably be selected if the “wrong” one was gone...?)

[Pavel Sobolev]

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.

[Bill Spitzak]

This bug seems pretty widespread, it might be best to just fix the Xlib rendering so that it uses 1-wide lines instead of 0-wide if there is any dash pattern.

On Tue, Sep 21, 2021 at 12:00 AM Pavel Sobolev <pave...@gmail.com> wrote:

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.