Initial ScaleFactor != 1.0 doesn't handle scale factor changed properly

[cfagot]

On ubuntu I used this command to change scale factor dynamically:

gsettings set org.gnome.desktop.interface text-scaling-factor 1.0

I tested using the masonry to_do_list.rs example.

If I start at scale factor 1 and change to scale factor 1.5 it works fine:

But if I start with scale factor 1.5 and switch to 1.0 I get this (error on bottom image after switching to 1.0):

My expectation would be that the top image (start 1.0) and the bottom image (start 1.5, switch to 1.0) would match.

Note that in a custom rendering widget I noted that something was amiss even in the start 1.5 case, but I will wait to see if a fix for this issue resolves that before creating a test case for it.

Putting prints into event loop (first print on resume, second on scale changed):
[Note: edited to fix reporting issue]:

Scale factor: 1.5
Size: PhysicalSize { width: 800, height: 600 }

Scale factor changed: 1
Size: PhysicalSize { width: 600, height: 600 }

Scale factor changed: 1.5
Size: PhysicalSize { width: 900, height: 900 }

Scale factor changed: 1
Size: PhysicalSize { width: 600, height: 600 }

Versus when starting at 1.0:

Scale factor: 1
Size: PhysicalSize { width: 800, height: 600 }

Scale factor changed: 1.5
Size: PhysicalSize { width: 1200, height: 900 }

Scale factor changed: 1
Size: PhysicalSize { width: 800, height: 600 }

Scale factor changed: 1.5
Size: PhysicalSize { width: 1200, height: 900 }

[DJMcNab]

What version of Xilem are you using? I'm unable to reproduce on main.

I don't understand why you claim that "If I start at scale factor 1 and change to scale factor 1.5 it works fine" - that rendering is also broken. It looks like the scale factor change also isn't applying there.

I believe that this was already fixed in #309.

[cfagot]

I thought I was testing on the most recent main, but looks like I was behind a bit, but definitely not that far behind. I'll re-test with everything updated.

I don't understand why you claim that "If I start at scale factor 1 and change to scale factor 1.5 it works fine" - that rendering is also broken. It looks like the scale factor change also isn't applying there.

Oh, I wasn't sure what it was supposed to do (I didn't look at the app_logic even). I just meant that it wasn't off screen. But, yeah, they are both broken.

[cfagot]

After updating I get the same thing. I'm on Ubuntu 22.04 w/ X11 FWIW.

Just to be absolutely sure something weird isn't happening with github sync fork operation I'll download Xilem straight from linebender instead of going through my fork.

[cfagot]

Grabbed fresh main branch from linebender and same result.

[DJMcNab]

Are there different programs which use winit which handle this properly? The fact that our code works as expected on other platforms suggests that something weird is happening with winit's handling for your platform.

I'm also not sure how to interpret your logs - I don't really understand what they're saying. Can you provide a video with live-updating logs?

I would also suggest that you try using Wayland.

[cfagot]

Unfortunately I can't switch to wayland on this machine because of the nvidia drivers. I'll see if I can find a different machine to test both wayland and x11 on.

The logs are printing out the size of the window when first created and then after each scale switch. This is done separately for starting at scale 1 and scale 1.5.

But I messed that up. I print the size after the scale change but should be doing it after the window is resized, which comes later. I'll redo the numbers just to get them right. But the images are probably enough to see that something is going amiss.

[cfagot]

I was able to test on both a windows laptop (one of the new fangled arm surface laptops) and an old ubuntu laptop running wayland. Scaling is working in both those cases. When I switch the ubuntu laptop to x11 the scaling breaks. So seems to be x11. Maybe someone else on x11 can confirm.

[cfagot]

Daniel, since I have a laptop where I can compare x11 and wayland I'll dig in more and see if I can figure out what is going on.

[cfagot]

Not having great luck.

One note on my wayland test: it wasn't quite right because wayland doesn't change scale factor when you change text scale. But if I change scale factor via display settings it still works on wayland (just less convenient for testing). And x11 continues to not work when changing that way.

When I logged the winit events that happened they were the same with x11 and wayland:

• We set size and scale inside resume when creating the window, and then we get a resize event right after resume.
• When scale is changed we get a scale event followed by a resize event.

The only difference I'm noticing between the two is that while both x11 and wayland emit a warning about "widget requested layout during layout pass" when first setting the scale (even though it's going from 1 to 1 in my test) only x11 emits that warning when going from scale 1 to 2. I tried to counter that by just calling root_layout() again in that case but although that squashes the warning it doesn't change behavior.

Other x11 malarkey: If I move the title bar just a little after the scale change it changes the size of the window to be most, but not all, of the screen (wayland does not spaz out like this). This new window seems to have things laid out properly. And this happens whether I move the window slightly vertically or horizontally. On the other hand, resizing by grabbing the window edge either on the side or the bottom does not have this effect (layout still wrong).

Anyway, going to put this down for now. If any of that rings a bell with anyone let me know and I can run more tests. Particularly confused how same winit events lead to different results -- but maybe masonry is making window calls internally that are being treated differently. Not familiar enough with code base to have intuition here.