Multi-backend rendering / null backend
kernle32dll opened this issue · comments
I'm currently working on a small cross-plattform rendering framework to cook up small, private projects. One of the core concepts required for this is the possibility to switch rendering backends on-the-fly.
The first step to this is go-gl/gl#85, which allows to have multiple OpenGL versions "initialized" at the same time. However, the deal breaker is this binding at the moment. As it stands, applications can only be compiled with either OpenGL 2 or 3 (+ glfw vs sdl) support - not both.
The long-term solution would be to move the rendering backends around (e.g. to a new backends package, with an unique naming stretegy), so that they can be used in conjunction (they cant at the moment due to deliberately same method names, kept disjunct only by build tags).
A possible short term solution would be to provide a (default?) build tag to compile no rendering backend at all - this would prompt the lib-user to write his or her own, but would also grant more freedom.
Combining both long and short term solutions could prompt extraction of the rendering backends to own projects, which can be maintained on their own (e.g. the planed(?) vulkan backend).
Unfortunately for Nuklear backend is more than just drawing API, it's also input handler with its own logic (e.g. map touch input to X-scroll event), I'm too lazy to refactor the package to move to interfaces. I'd rather will be busy on working on pure-Go UI library which is in developement.
A possible short term solution would be to provide a (default?) build tag to compile no rendering backend at all
Ok, we can add a build tag for that, but since the package is go-getable the default will still be OpenGL3. Would you suggest the name?
which can be maintained on their own (e.g. the planed(?) vulkan backend).
Vulkan backend will be merged here, it won't be a separate package.
Ok, we can add a build tag for that, but since the package is go-getable the default will still be OpenGL3. Would you suggest the name?
Fine by me. Probably something like "nobackend"?
busy on working on pure-Go UI library which is in development
How far along are you with that? /me is wondering, @xlab
@tcurdt sorry, not even moved. I have floating focus on things, UI is currently out of focus and I forgot most of the ideas I had in September :(
@tcurdt it's just announced that Cairo now supports GLESv3 rendering backend and may target Vulkan in the future. This triggers me, I think I will make this to be my side project for the upcoming holidays :)
https://blogs.s-osg.org/introducing-cairo-gl-es-v3/
🎁
@tcurdt I've created bindings for Cairo http://github.com/golang-ui/cairo so it's easy to create graphic stuff from scratch. I'll be working on UI library in the upcoming weekends. At least Cairo is more sophisticated than Nuklear in terms of graphics and text rendering (see Pango Cairo, etc).