Red Artist

If there is going to be a partial low level rewrite of egui api, then we might as well check if the new api will be suitable to write bindings...

this might soon be possible with https://github.com/rust-windowing/winit/pull/2232

is https://docs.rs/egui/latest/egui/struct.Response.html#method.drag_released what you want?

https://github.com/emilk/egui/issues/683 related issue of what happens when the menu overflows the screen (in this case) and vertically (in the linked issue). for vertical overflows, scrolling was considered in the PR...

Did you try release mode? How's the CPU or GPU usage looking when you are running the app?

I think there are some good points in support of wgpu. 1. debugging builtin with wgpu. trace feature + debug_groups. 2. crashes instead of segfault if there's some bug 3....

btw, I'm not asking three-d to support compute shaders. three-d can stay simple (as it is right now), and only expose the current high/mid API abstracting over wgpu / openGL....

if i wanted to add wgpu backend to three-d, where would i start? start porting the shaders and mid-level api? I just realized that `three-d` uses custom windowing code for...

understood, i will start by first porting to winit, which is useful regardless of the wgpu stuff. not urgent, but one thing that will need consideration for high level APIs...

porting to winit was pretty easy. but I give up on adding wgpu to three-d. It is very much possible to do so, but first, rewriting it from scratch seems...