goxjs
Update to newest "golang.org/x/mobile/gl"
I'm currently investigating my options for writing an OpenGL application for both desktop and web and this repository seems the be the best candidate - good work!
It is a while since it was forked from "golang.org/x/mobile/gl" and it seems that there were quite some major changes - adding WebGL support wasn't one of them. One change I like particularly is the render-thread: Applications use a glctx-object that exposes the OpenGL functionality, but the calls to that context are only pushed into a channel and executed later by a dedicated render thread. This improves multithreading / go-routine support greatly.
I'm not able to use "golang.org/x/mobile/gl" due to the lack of WebGL support (I don't need to support mobile). And I also don't like the fact that desktop applications require the ANGLE dlls instead of using the OpenGL bindings from go-gl - but I can live with that.
Is it possible for goxjs to adapt those features or to be updated to the newest version of golang.org/x/mobile/gl? Which changes would be required to do so?
Thanks for your interest in this package.
The upstream golang.org/x/mobile/gl has indeed made some internal changes since the fork point, the major one being the render-thread you mentioned.
I don't currently have plans to work on backporting this feature for goxjs/gl, because for my needs, the current implementation works sufficiently well. Before the render-thread can be implemented, it would need to be evaluated. If you're interested in doing that, I recommend doing it on a fork and letting me how it goes.
The only short term plans I have for goxjs/gl development right now is the addition of WebAssembly support, as can be previewed on the wasm branch.
Thanks for the fast answer. I'm currently working on a small engine and decided to use x/mibile/gl for now.
But once I'm confident enough in that project to add WebGl support, I wouldn't mind switching to goxjs and to add the missing features there.
x/mobile seems to have way too much overhead if "only" OpenGL is needed. It's more like an experimental framework than a library.
What is your opinion about a dedicated glContext interface instead of global package functions? And what is your attitude regarding breaking changes or releasing a v2?
Thanks for the fast answer. I'm currently working on a small engine and decided to use x/mibile/gl for now.
But once I'm confident enough in that project to add WebGl support, I wouldn't mind switching to goxjs and to add the missing features there.
Sounds like a good approach.
If you want to make big changes to goxjs/gl, I recommend you work on a fork and feel free to share updates. I'm unlikely to have time to review big PRs.
x/mobile seems to have way too much overhead if "only" OpenGL is needed. It's more like an experimental framework than a library.
x/mobile/gl was created primarily for accessing OpenGL on mobile devices (iOS and Android). Desktop support was added later, mostly to aid development.
What is your opinion about a dedicated glContext interface instead of global package functions?
It's reasonable to consider when making a new API, but it's a large change, and one needs to evaluate the benefits and costs. At this time, I don't have a strong desire to make such a change.
And what is your attitude regarding breaking changes or releasing a v2?
Breaking API changes to fix bugs in the API can be considered, but otherwise I'd like to keep the API stable. v2 is fine, but I don't have plans to work on one myself soon.