every 4 or 5 pixels, widget gets sized slightly smaller than the window

[makoConstruct]

Running 0.5.0 on linux (openbox window manager, compositing on), a single widget with a layout implementation that just returns bc.max() will sometimes (even after resize events have ceased) be left lagged a little bit behind the real size of the window. A single pixel void sits open between the widget and the edge of the window.

to reproduce, get simple program with maximised widget:

use druid::{ AppLauncher, WindowDesc, LocalizedString, widget::{ Button } };
fn main(){
	AppLauncher::with_window(WindowDesc::new(|| Button::new("uh"))).launch(()).unwrap();
}

Resize it quickly, you'll see a grey edge flicker in and out when increasing the size. If you stop abruptly enough, sometimes it will stay visible.

[cmyr]

I'm not sure what this might be, but maybe someone running gtk can look into it?

[luleyleo]

I can't reproduce it 🤔
@makoConstruct Are you using X11 or Wayland?

[xStrom]

What resolution scale do you have? 1 pixel = 1 device pixel, or something else?

[makoConstruct]

I can't reproduce it
@makoConstruct Are you using X11 or Wayland?

X11.

What resolution scale do you have? 1 pixel = 1 device pixel, or something else?

There is indeed something weird about my resolution, but I can't see how it would be related.

I'm using a former TV screen and a lot of apps (Qt, mostly) will render with really stupid proportions until I alter some environmental variable. Druid, however, doesn't seem to have this issue.

[makoConstruct]

New observations! It's not about lagging behind the resize frontier, at least in the button example. The edge appears (if I'm counting right), every four or five pixels, starting at 1, then appearing at 5, 10, 14, 19, 23, 28 etc. Each multiple of.. some number between 4 and 5, will not lay out the child widget correctly.

[makoConstruct]

However, speed of resizing does play a role, sometimes the edge will be thicker (more than 1 px wide) if you're resizing the window very quickly.

[xStrom]

I can't reproduce this on Ubuntu 19.04 or 19.10. Tried both druid 0.5 and master with scale factor 1 and 2.

I'll ask again though, what is your scale factor? 1? 2? Something fractional?

Generally it's looking more likely now that this is some sort of issue with either GTK or your specific setup.

To check whether this is a druid bug you can create a root Widget that will just paint itself a solid color and also log the WindowSize event. Then reproduce the issue and see if the WindowSize event reported a size equal to the painted color or larger.

[makoConstruct]

I didn't really know what specific information you were asking for or how to get it. I'm still not totally sure what that is or where it would be stored, searching suggested you might be talking about one of these command outputs
» xdpyinfo | grep -B 2 resolution
screen #0:
dimensions: 1920x1080 pixels (1626x914 millimeters)
resolution: 30x30 dots per inch
(this dpi is less than half of what it should be, measuring yields about 70)
» gsettings get org.gnome.desktop.interface scaling-factor
uint32 0
I am not running gnome though, I'm trying to check xfce's settings for scale factor and... it seems like the version I have (it could be old) just doesn't have that anywhere.

To check whether this is a druid bug [...]

Widget renders at 54 wide, while window is 55 wide, and while widget reports a WindowSize event of 53.76

(minor note: I tried sizing the window back and forth by a pixel to see if it was lagging behind and reporting the last size instead of the current size, or something. It wasn't doing that.)

[xStrom]

I'm not sure where exactly the DPI scale factor is stored in all these Linux flavors either, that's why I can't be super specific.

However we can go at it from druid's side instead and see what druid thinks it is. We could add a debug print after these lines in druid-shell/src/platform/gtk/window.rs.

println!("DPI {} stretches {} to {}", dpi_scale, extents.width, size.0);

Then as you reproduce the issue, see what the final printed line is in the terminal and report it back here.

The 53.76 you saw for WindowSize suggests there might indeed be something interesting going on with scale.

[makoConstruct]

before the bug is occurring: DPI 0.78125 stretches 182 to 142
and then once it's occurred: DPI 0.78125 stretches 183 to 142

[xStrom]

This is very helpful. I'll force my Ubuntu to use this exact same DPI later today and see if I can reproduce it.

[xStrom]

Just to give a quick update, I have this issue fixed in my development branch but it'll take a bit more time for me to submit a PR.