-
-
Notifications
You must be signed in to change notification settings - Fork 10.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Which of the backends are most portable? #7177
Comments
I would be inclined to try out SDL2 as it can fall back to software rendering I haven't tried this but have seen that there is an openGL software renderer Mesa3D which might be handy. (You can drop in and override the default openGl 1.1 dll in windows) I have seen some posts about virtualbox supporting openGL 2.1, dx3d8/9 GLFW not starting in a VM to me sounds more like a glfw issue, older versions of virtualbox seems to support openGL2.1 which should work, I tend to like SDL over glfw in older/limited stuff like this, I find it handles across a little more stuff. Seems like a cool project kinda need a camera interface for some older onvif cameras :D |
Another choice: https://github.com/google/angle I'm compiling my app with OpenGL ES + angle on Windows: tsl0922/ImPlay#15 |
Closing as answered.
You could add support for it in the renderer. DX11 also support software rendering mode via WARP. |
I have a windows / linux app (https://github.com/dicroce/revere) that uses imgui. So far, I have used the glfw + opengl backends. I had hoped this would be the most portable choice... but I am running into glfw issues when trying to create a window inside of virtualbox vm's. Virtualbox does not properly support opengl applications.
I tried using a GDI renderer I found online but it doesn't look like it supports Image() (which I absolutely need).
So far, all of the software renderer backends I've seen also lack support for using custom textures (needed for Image() I believe).
It's frustrating because it really does seem like if imgui_impl_win32 + software renderer (and likewise an imgui_impl_x11 + software renderer) would provide the most portable solution.
So, I guess my final question is: Is there some combination of backends that I could use on Windows (and a corresponding pair I could use on linux) that will be more likely to work out of the box than glfw + opengl?
The text was updated successfully, but these errors were encountered: