How does the event loop system work for this library?

[AeroSW]

Hello,

I'm quite new to Rust, but I have extensive experience with C/C++. I'm wanting to use your WINIT crate to build out a Vulkan Renderer. I'm currently following Kyle Mayes's Vulkanalia Guide which utilizes the 0.29 version of WINIT. Sadly, it appears in 0.30.0 the WindowBuilder Struct was deprecated, which was used in this guide. I plan to alter the initial setup, but I can't figure out how to get ActiveEventLoop from EventLoop. I assume there is an underlying reason for the obfuscation of how to attain this model through the usage of the initial base EventLoop creation. Do you mind clarifying how your Event Loop system works, or possibly providing a link to a guide on it?

[XCemaXX]

I have the same problem with WindowBuilder. I tried my best, but I cannot solve async problem with request_adapter and request_device.
Signature: fn request_adapter(...) -> impl Future<Output = Option<wgpu::Adapter>> + WasmNotSend
Code in winit 0.29:

fn create_window<T>(event_loop: &EventLoop<T>) -> Result<Window, OsError> {
    use winit::platform::web::WindowBuilderExtWebSys;
    //init dom_canvas...
    let canvas = dom_canvas.dyn_into::<web_sys::HtmlCanvasElement>().ok();
    WindowBuilder::default().with_canvas(canvas).build(event_loop)
}

#[wasm_bindgen(start)]
pub fn start() {
    std::panic::set_hook(Box::new(console_error_panic_hook::hook));
    console_log::init().expect("could not initialize logger");
    let event_loop = EventLoop::new().unwrap();
    let window = create_window(&event_loop).unwrap();
    wasm_bindgen_futures::spawn_local(run(event_loop, window));
}

async fn run(event_loop: EventLoop<()>, window: Window) {
    let mut render_state = Render::new(&window).await; // <= async because of Surface.request_adapter and request_device inside
    let window = &window;
    event_loop
        .run(move |event, target| {
            if let Event::WindowEvent { ... } ...
        }).unwrap();
}

I made changes for winit 0.30 which doesn't work. I even tried tokio::runtime::Runtime::new().block_on(Render::new(&self.window.unwrap())) but I cannot use this in webasm. Actually, I don't want to bring tokio to the project.

#[derive(Default)]
struct App<'a> {
    window: Option<Window>,
    render_state: Option<Render<'a>>, // <= should live long as window
}

impl ApplicationHandler for App<'_> {
    fn resumed(&mut self, event_loop: &ActiveEventLoop) {
        use winit::platform::web::WindowAttributesExtWebSys;
        //init dom_canvas...
        let canvas = dom_canvas.dyn_into::<web_sys::HtmlCanvasElement>().ok();
        self.window = Some(event_loop.create_window(Window::default_attributes().with_canvas(canvas)).unwrap());
        self.render_state = Some(Render::new(&self.window.unwrap()).await); // <= PROBLEM HERE. It is async
    }
    fn window_event(&mut self, event_loop: &ActiveEventLoop, id: WindowId, event: WindowEvent) {
        let window = &self.window.unwrap();
        let render_state = &self.render_state.unwrap();
        match event {...}
    }
}

#[wasm_bindgen(start)]
pub fn start() {
    std::panic::set_hook(Box::new(console_error_panic_hook::hook));
    console_log::init().expect("could not initialize logger");
    let event_loop = EventLoop::new().unwrap();
    let mut app = App::default();
    let _ = event_loop.run_app(&mut app);
}

Guys, help please to solve this puzzle.

[XCemaXX]

Actually, I found out how to solve async part with pollster::block_on. But I got another lifetime problem. Code:

pub struct Render<'a> {
    surface: wgpu::Surface<'a>,  //    ...
}
impl<'a> Render<'a> {
    pub async fn new(window: &'a Window) -> Render<'a> {
         let instance: wgpu::Instance = wgpu::Instance::default();
         let surface = instance.create_surface(window).unwrap();
         Self { surface, /* ... */ }
}}

#[derive(Default)]
struct App<'a> {
    window: Option<Window>,
    render_state: Option<Render<'a>>,
}

impl<'a> ApplicationHandler for App<'a> {
    fn resumed(&mut self, event_loop: &ActiveEventLoop) {
        //           - let's call the lifetime of this reference `'1`
        use winit::platform::web::WindowAttributesExtWebSys;
        // init dom_canvas...
        let canvas = dom_canvas.dyn_into::<web_sys::HtmlCanvasElement>().ok();
        self.window = Some(event_loop.create_window(Window::default_attributes().with_canvas(canvas)).unwrap());
        let r = pollster::block_on(Render::new(self.window.as_ref().unwrap())); // it is ok
        self.render_state = Some(r);
        //^^^^^^^^^^^^^^^^^ assignment requires that `'1` must outlive `'a`
    }

[oligamiq]

One resolution is Box::leak(Box::new()) and create guard class and mem::drop trait.
You get Render 'static.

※I am not familiar with this library and wgpu so I am sure there is a better way.

[XCemaXX]

Ok, thanks. I will try.
This is actually "self-reference struct" problem - and one of the favorite newbie topic in rust as I understand.

[AeroSW]

So, I'm not sure about these comments. These are not answers for my question. My question was on how 0.30.0 works. I wanted to understand the new workflow/event system. I have already successfully replaced the code in that tutorial, but I'm still treating WINIT as a black box, and I would prefer to not just use it as such. I would like to understand the library.

[kchibisov]

The code is relatively simple so you can just try reading one backend, like e.g. wayland one, they are more traditional. But basically, the event loop is usually something like epoll (depends on the platform, I'd use epoll for simpliticy), this is what is behind the EventLoop` itself.

Once you run the loop, with one of the run APIs, you pass some state: &mut dyn ApplicationHandler (just a fat pointer to something implementing the trait), and then winit calls back to you once it gets event from the windowing system.

The ActiveEventLoop is the same as EventLoop under the hood, it's just a different type to make calls more safe to do, because on e.g. macOS you could be required to have event loop running.

What each backend uses for EventLoop is different for each platform, but it's some native mechanism (just look into the code for that, like is using something like libevent, but in rust, macOS is CFRunLoop, and windows some win32 stuff).

I'd also suggest to read the Event enum, I think, which should document how things arrive, and look at ControlFlow stuff. But it all boils down to something like that:

loop {
    event_loop.poll_events(timeout, &mut event_buffer);
    user_state.new_events(&event_loop);
    for event in event_buffer {
         user_state.dispatch(&event_loop, event); // Just call the right method
    }

    user_state.about_to_wait(&event_loop);
}

The 0.29 works exactly the same btw, it's just instead of state there's a callback, but the logic is exactly the same (in fact it's still callback internally and state is used only at the very top for this release, internal callback and indirection will all go away from the next release).

But again, it's better to get familiar with a particular backend and ask particular maintainer in the matrix room if you're more curious how things work, I can consult on like(in order of my understanding) Wayland, X11, macOS, and general stuff.