Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Examples do not paint the UIs on startup. #166

Open
phillipbaird opened this issue Nov 11, 2023 · 3 comments
Open

Examples do not paint the UIs on startup. #166

phillipbaird opened this issue Nov 11, 2023 · 3 comments
Labels
S: help wanted Status: Extra attention is needed T: bug Type: Something isn't working

Comments

@phillipbaird
Copy link

Have just discovered Floem (via This Week in Rust) and have been looking at the examples.

Problem:
None of the examples paint their UIs upon startup (at least on my system).
The winit window frame is displayed but the window content is just whatever was on screen behind the window when it opened.
The only action that triggers the UI to start painting itself is resizing the window.
Via the Counter example I can observe that I can click on the buttons that are not visible (the console reports when the counter is reset). These application state changes do not trigger the UI to paint itself.
Once the window has been resized to trigger the first paint of the UI the examples work as intended.

Environment
rustc: 1.73.0 - stable-x86_64-unknown-linux-gnu
Operating System: Arch Linux
KDE Plasma Version: 5.27.9
Kernel Version: 6.6.1-arch1-1 (64-bit)
Graphics Platform: X11
Graphics Processor: NVIDIA GeForce GTX 1080

Please let know what else I can do to assist solving this problem.

Thanks.

@jrmoulton
Copy link
Collaborator

Awesome to hear! (about This Week in Rust that is).

I'm not experiencing this issue and since I'm on macOS I don't have any great way to debug it directly. There may have been some recent changes that would affect painting the first frame. Could you try checking out this commit from about a month ago 5dd6c86 and see if the issue is still there? If it's working in that commit could you run a git bisect to find the commit where it broke?

@phillipbaird
Copy link
Author

It looks like the bump to winit on 25th October is where the problem starts.

cf4c09e - is the last commit that works for me
d7a9356 - bumps winit - does not compile
6fbaf7e - compiles and where I can observe the problem for the first time.

Hope that helps.

@phillipbaird
Copy link
Author

Have discovered the problem can be worked around by supplying a WindowConfig with a custom window size.

fn main() {
    let window_config = WindowConfig::default().size(Size {
        width: 1920.0,
        height: 1080.0,
    });
    floem::Application::new()
        .window(move |_| app_view(), Some(window_config))
        .run();
}

@panekj panekj added T: bug Type: Something isn't working S: help wanted Status: Extra attention is needed labels Dec 9, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S: help wanted Status: Extra attention is needed T: bug Type: Something isn't working
Projects
None yet
Development

No branches or pull requests

3 participants