You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, we sort-of re-implement a small fraction of glutin::WindowBuilder in our three::Builder. Given that glutin just re-exports winit, and that one is cross-platform and used by gfx-rs's windowing crates, I believe we should be basing around it.
There are only 2 properties we need (so far) outside of winit stuff: vertical sync and shader path. Perhaps, we could make this work like:
The thing I like in our current design is that it needs just a few steps to adjust some settings.
For example, it's common situation for me when I need to load shaders from some path for some example. With current design, all I need is:
change new to builder
add new shader_directory(...) function call
end up with build()
With this approach I would need to add new WindowSettings struct, set up winit::WindowBuilder and change new(...) to from_settings(...).unwrap().
Currently, we sort-of re-implement a small fraction of
glutin::WindowBuilder
in ourthree::Builder
. Given thatglutin
just re-exportswinit
, and that one is cross-platform and used bygfx-rs
's windowing crates, I believe we should be basing around it.There are only 2 properties we need (so far) outside of
winit
stuff: vertical sync and shader path. Perhaps, we could make this work like:The second choice would be for clients who need to fine-tune everything, and they can handle the error if something goes wrong.
The text was updated successfully, but these errors were encountered: