PistonDevelopers / window

DEPRECATED - moved into the piston repo
MIT License
0 stars 4 forks source link

Add fallback on backends. #37

Open Potpourri opened 9 years ago

Potpourri commented 9 years ago

Currently glfw_window and sdl2_window panics if OpenGL version not supported, glutin_window writes error, but not panics. I propose to make it customizable. Add in WindowSettings field fallback or something similar. In backends panics if is false and try to create context with default OpenGL if is true.

bvssvni commented 9 years ago

Perhaps we should return Result<Window, Error> from the back-ends.

Potpourri commented 9 years ago

What is the minimum version OpenGL we support? We everywhere use 3.2, but 2d works well and with 2.1. It would be nice to have fallback to it.

bvssvni commented 9 years ago

The OpenGL version shouldn't be put in WindowSettings, because the back-end might be using DirectX or a software rasterizer. That's why it passed as first argument and WindowSettings is passed as second.

Potpourri commented 9 years ago

I do not ask put OpenGL version in WindowSettings. I ask what is the minimum version OpenGL we support in piston projects? If it 3.2 and low versions we will not support, then no problem. But if we support low versions, then we need fallback or somethings else.

Potpourri commented 9 years ago

Here is an example: OpenGL = 3.2 (it passed as first argument, all as always) fallback = true (it set in WindowSettings or passed as third argument, it does not matter) Backend first try to create OpenGL 3.2 context. If it fail, then check fallback flag, if fallback = true, then backend prints error and creates context with maximum available OpenGL version, else if fallback = false, then backend panics or perhaps returns Err(...). Something like currently works glutin_window, only in him this behavior is not customizable.

bvssvni commented 9 years ago

Ok, so the window back-end attempts to fall back on an earlier version when fallback = true. This would increase the range of hardware the application runs on and cause less problems for users.

As a first step, can we make a custom constructor per window back-end GlutinWindow::fallback(version, settings)?