Welcome to tomaka/glutin, the official gitter channel for Glutin and Winit! - Github: https://github.com/rust-windowing/glutin, https://github.com/rust-windowing/winit - Crates.io: https://crates.io/crates/glutin, https://crates.io/crates/winit - Docs: https://docs.rs/glutin/0.21.0/glutin, https://docs.rs/winit/0.20.0/winit/
UndeadLeech on Freenode So it's completely up to that at which point the cleared event is to be emitted.
Ralith xlib has its issues but it should damn well be able to tell that the queue is not empty :P
orchaldir Hi, I have a question about the event loop. I use glutin::event_loop::ControlFlow::WaitUntil with 60 hz and update/render on ResumeTimeReached & RedrawRequested. It works fine until I move the mouse. Then I only get MainEventsCleared, RedrawEventsCleared, Motion & MouseMotion. To which event should I react to keep the 60 hz?
UndeadLeech on Freenode It shouldn't matter when you get woken up or for what reason you got woken up.
Ralith if you want to redraw continuously, just do it in the events cleared event directly
UndeadLeech on Freenode What's up?
Phoenix K I created a crate which abstracts away winit's inversion of control. I'm wondering if anyone 1. recognizes it as similar to existing work 2. thinks it's a good or bad idea.
Phoenix K It works by spawning your "virtual main thread" in a second thread, and hijacking the real main thread with the event-loop, and using communication between the threads to let your program be structured as if winit didn't hijack the main thread.
Phoenix K Here's the example from winit's readme, adapted to utilize this library:use winit_main::{
self,
reexports::{
event::{Event, WindowEvent},
window::WindowAttributes,
},
EventLoopHandle,
EventReceiver,
};
#[winit_main::main]
fn main(event_loop: EventLoopHandle, events: EventReceiver) {
println!("creating window");
let window = event_loop
.create_window(WindowAttributes::default())
.unwrap();
for event in events.iter() {
println!("received event: {:?}", event);
if matches!(
event,
Event::WindowEvent {
event: WindowEvent::CloseRequested,
window_id,
} if window_id == window.id()
) {
break;
}
}
println!("exiting");
}UndeadLeech on Freenode What's the point exactly?
Phoenix K Abstractly, I would rather be able to write code like any other code, and treat the event loop as an iterator of events which I can call functions on to create and destroy windows, etc.
UndeadLeech on Freenode I don't see how that's not already the case.
Phoenix K More concretely, for example, this could turn into something that combines with tokio, and allows the event loop to be used neatly from the context of a tokio runtime.
UndeadLeech on Freenode Yeah, it's a function. That's not that special?
Phoenix K Hm, but it's an inversion of control. That has a couple of undesirable properties, including:- It's difficult to add inversion of control to a program after the fact, it tends to fundamentally affect the program's architecture.
- For the above reason, it's difficult to write programs which are generic between inversions-of-control, or to modify a program from using one inversion-of-control framework to using a different framework.
- It's tricky to use several inversions of control simultaneously. For example, it would be difficult to combine tokio with winit without creating additional abstractions.
Phoenix K Ah, thank you. Interesting, that one looks like it's async.
Phoenix K (This one is blocking)
Phoenix K Also seems to be a more complete abstraction. It looks like it defines its own set of event types entirely, whereas I just re-export winit's. Interesting.
maroider For better or for worse.
Phoenix K * I have a sort of a question. If I were making a game with winit, how would I enable v-sync? Is this something I would even do with the windowing API, or would that logic be somewhere else entirely?
maroider > <@phoenixk:matrix.org> I have a sort of a question. If I were making a game with winit, how would I enable v-sync? Is this something I would even do with the windowing API, or would that logic be somewhere else entirely?
V-sync is managed through rendering APIs, rather than through windowing APIs.
maroider > <@phoenixk:matrix.org> I have a sort of a question. If I were making a game with winit, how would I enable v-sync? Is this something I would even do with the windowing API, or would that logic be somewhere else entirely?- V-sync is (to my knowledge) managed through rendering APIs, rather than through windowing APIs.
UndeadLeech on Freenode That's correct. Like this with glutin for example: https://docs.rs/glutin/0.26.0/glutin/struct.ContextBuilder.html#method.with_vsync