xlab
commented
6 years ago 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.
kernle32dll
tcurdt
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 https://github.com/go-gl/gl/issues/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).