Infinite negative dimensions on window

[saghm]

The windows created by eframe on my system seem to not be able to detect their dimensions, which I noticed due to ViewportBuilder::with_min_inner_size not doing anything. (To potentially save time for people reading this, I suspect this is due to my somewhat bleeding-edge desktop environment, which I included details about below in the relevant section).

To Reproduce

Steps to reproduce the behavior:

1. Put the following contents into the respective files:

# Cargo.toml
[package]
edition = "2021"
name = "scratch"
version = "0.1.0"

# This happens both on the latest published version and when depending directly on the latest master branch
[dependencies]
#eframe = "0.26.2"
eframe = { git = "https://github.com/emilk/egui", branch = "master" }

# src/main.rs
use eframe::{egui::ViewportBuilder, NativeOptions};

fn main() {
    eframe::run_simple_native(
        "is this dark matter?",
        NativeOptions {
            viewport: ViewportBuilder::default().with_min_inner_size([1000.0, 1000.0]),
            ..Default::default()
        },
        |ctx, _| {
            dbg!(ctx.used_size(), ctx.used_rect());
        },
    )
    .expect("wait that wasn't supposed to be what went wrong...");
}

2. cargo run or cargo run --release

3. Check that the window is rendered properly

4. Check the print output and see the following:

[src/main.rs:11:13] ctx.used_size() = [-inf -inf]
[src/main.rs:11:13] ctx.used_rect() = [[inf inf] - [-inf -inf]]
[src/main.rs:11:13] ctx.used_size() = [-inf -inf]
[src/main.rs:11:13] ctx.used_rect() = [[inf inf] - [-inf -inf]]
[src/main.rs:11:13] ctx.used_size() = [-inf -inf]
[src/main.rs:11:13] ctx.used_rect() = [[inf inf] - [-inf -inf]]
[src/main.rs:11:13] ctx.used_size() = [-inf -inf]
[src/main.rs:11:13] ctx.used_rect() = [[inf inf] - [-inf -inf]]
...

Expected behavior

The dimensions reported by Context::used_rect and Context::used_size would be accurate (presumably positive, given that the window does seem to render fine) and the minimum size specified would be respected.

Screenshots

Desktop:

I suspect this might be where the issues lies; I'm using Plasma 6 from the Arch Linux testing repos, which only became available this week.

• OS: Linux (details from uname shown below)

→ uname -a
Linux bunchacrunch 6.7.8-zen1-1-zen #1 ZEN SMP PREEMPT_DYNAMIC Sun, 03 Mar 2024 00:30:23 +0000 x86_64 GNU/Linux

• Wayland (see attached output of wayland-info for details)

wayland_info.txt

I'm unfortunately not sure what the best way to determine which rendering output is being used by eframe. I'm fairly certain that it's not using X11 because I generally can identify windows using XWayland by using wmctrl because it doesn't ever list info about native Wayland windows, and it similarly doesn't have any output related to the window opened by eframe. I'm not sure if it's using the wayland backend or glow (or if those are entirely different things rather than mutually exclusive options; I'm pretty inexperienced in programming GUIs).

Assuming this isn't reproducible easily on other desktops, I'm happy to add any additional info (either from my system or updating the repro code to print something else) that would be helpful to try to narrow cause what's causing this! If there's a different destkop environment that would be helpful for me to check, it shouldn't be too much of an issue; reverting back to Plasma 5 to test this would unfortunately be a bit of a pain given that I plan to keep using 6, but if there's no other way to sanity check things, I might be able to find an old laptop or something to boot up and try it out on that.

[rustbasic]

Internal information must be used using ctx.input().

use eframe::{egui::ViewportBuilder, NativeOptions};

fn main() {
    eframe::run_simple_native(
        "is this dark matter?",
        NativeOptions {
            viewport: ViewportBuilder::default()
                .with_min_inner_size([1000.0, 1000.0]),
            ..Default::default()
        },
        |ctx, _| {
            dbg!(ctx.used_size(), ctx.used_rect());
            let monitor_size = ctx.input(|i| i.viewport().monitor_size);
            let inner_rect = ctx.input(|i| i.viewport().inner_rect);
            let outer_rect = ctx.input(|i| i.viewport().outer_rect);
            println!("{:?}", monitor_size);
            println!("{:?}", inner_rect);
            println!("{:?}", outer_rect);
        },
    )
    .expect("wait that wasn't supposed to be what went wrong...");
}

[saghm]

Thanks for the tip! I updated the print statements you gave to identify which value was being printed to make sure I could differentiate them, and I got this as the first set of results (with the print statements repeating the last three values afterwards):

monitor size: None
inner rect: None
outer rect: None
monitor size: None
inner rect: None
outer rect: None
monitor size: Some([2048.0 1152.0])
inner rect: None
outer rect: None
monitor size: Some([2048.0 1152.0])
inner rect: None
outer rect: None
monitor size: Some([2048.0 1152.0])

I imagine that the None values on the first two sets of calls are just from it taking a moment to start up. My monitor is 2560x1440, but I use a 125% scaling factor, so I think the monitor size seen by the the view port is reasonable. I'm not sure why inner_rect and outer_rect are always returning None though, but it seems likely that's related to why the size restriction isn't being followed.

[rustbasic]

That works fine on windows.
Please check again as follows.

use eframe::{egui::ViewportBuilder, NativeOptions};

fn main() {
    eframe::run_simple_native(
        "is this dark matter?",
        NativeOptions {
            viewport: ViewportBuilder::default().with_min_inner_size([1000.0, 1000.0]),
            ..Default::default()
        },
        |ctx, _| {
            egui::CentralPanel::default().show(ctx, |ui| {
                let monitor_size = ui.ctx().input(|i| i.viewport().monitor_size);
                let inner_rect = ui.ctx().input(|i| i.viewport().inner_rect);
                let outer_rect = ui.ctx().input(|i| i.viewport().outer_rect);
                println!("{:?}", monitor_size);
                println!("{:?}", inner_rect);
                println!("{:?}", outer_rect);
            });
        },
    )
    .expect("wait that wasn't supposed to be what went wrong...");
}

[saghm]

Hmm, this has the same issue, but weirdly it reports slightly different dimensions for the monitor as a whole:

Some([2048.0 1152.0])
None
None
Some([2048.0 1152.0])
None
None
Some([2048.0 1152.0])
None
None
Some([2048.0 1152.0])
None
None
Some([2048.0 1152.0])
None
None
Some([2048.0 1152.0])
None
None
Some([2048.0 1152.0])
None
None
Some([2048.0 1152.0])
None
None
Some([2048.0 1152.0])
None
None

[rustbasic]

There is no problem on Windows, so I think someone using Linux will have to solve it.

[saghm]

Yeah, I suspect this might even be more specific than just Linux in general. I'm having this issue on the Plasma 6 desktop environment that just came out last week, so I wouldn't be surprised if this is specific to that DE.

[rustbasic]

Yeah, I suspect this might even be more specific than just Linux in general. I'm having this issue on the Plasma 6 desktop environment that just came out last week, so I wouldn't be surprised if this is specific to that DE.

Can you apply the following to check if there are any problems and let me know the results?

Pull Requests #4182

[saghm]

Thanks for the suggestion! Running off that branch seems like it might have fixed the issue; the window starts up with a size lower than the minimum I set, but then as soon as I try to adjust it, the size immediately becomes the minimum I set and then won't allow resizing lower. I imagine that I should be able to just set the initial size manually to the same as the minimum to avoid needing to do that initial adjustment.

[rustbasic]

It seems to be the same problem as below.

Related content :

• On wayland ViewportCommand::InnerSize doesn't update the content size #4196
• Fix InnerSize command not resizing viewport #4207

[rustbasic]

@saghm

Could you try applying the information below one more time and let me know the results?

Pull Request :

• (rustbasic) In Progress : Testing... #4182