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

build_windowed() is very slow #1238

Closed
ApoorvaJ opened this issue Nov 19, 2019 · 4 comments
Closed

build_windowed() is very slow #1238

ApoorvaJ opened this issue Nov 19, 2019 · 4 comments

Comments

@ApoorvaJ
Copy link

ApoorvaJ commented Nov 19, 2019

Call to build_windowed() takes over 550ms in a release build. The result is a noticeable white window flash before the program starts.

Minimal repro code:

use glutin::event::{Event, WindowEvent};
use glutin::event_loop::{ControlFlow, EventLoop};
use glutin::window::WindowBuilder;
use glutin::ContextBuilder;
use std::time::SystemTime;

fn main() {
    let el = EventLoop::new();
    let wb = WindowBuilder::new();

    let time = SystemTime::now(); // <--- From here

    let _windowed_context = ContextBuilder::new().build_windowed(wb, &el).unwrap();

    println!("{:?}", SystemTime::now().duration_since(time).unwrap()); // <--- To here takes over 550ms

    el.run(move |event, _, control_flow| {
        *control_flow = ControlFlow::Wait;

        match event {
            Event::LoopDestroyed => return,
            Event::WindowEvent { ref event, .. } => match event {
                WindowEvent::CloseRequested => *control_flow = ControlFlow::Exit,
                _ => (),
            },
            _ => (),
        }
    });
}

glutin version: 0.22.0-alpha5
rustc version: rustc 1.39.0 (4560ea788 2019-11-04)
Windows 10 64-bit,
NVIDIA RTX 2080, Driver 436.48

I have a repro on glutin 0.21.1 as well. I do not have a repro if I only use winit.

@goddessfreya
Copy link
Contributor

I'm not familiar with what tools are available on windows, but could you profile the code and provide something like a flame graph?

@ApoorvaJ
Copy link
Author

Might take me a little time to get to it, but I will try to dig deeper.

@ApoorvaJ
Copy link
Author

Still haven't profiled it myself, but based on this Twitter thread and this forum post, this seems to be a common problem with NVIDIA OpenGL drivers' implementation of SetPixelFormat/ChoosePixelFormat.

@ApoorvaJ
Copy link
Author

ApoorvaJ commented Nov 29, 2019

I did a manual partial flame graph using llogiq/flame, and over half of the time is indeed spent on ChoosePixelFormat. Given that this behavior is well-documented by other folks, and that the fault lies entirely in the NVIDIA OpenGL driver, I'm not going to pursue this any further.

ChoosePixelFormat takes about 300ms out of the total 550ms startup time.

Feel free to close this issue, or keep it around for posterity in whatever form you see fit.

image

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

2 participants