Skip to content
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

Update to newest "golang.org/x/mobile/gl" #28

Open
maja42 opened this issue Jan 13, 2019 · 3 comments
Open

Update to newest "golang.org/x/mobile/gl" #28

maja42 opened this issue Jan 13, 2019 · 3 comments

Comments

@maja42
Copy link

maja42 commented Jan 13, 2019

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?

@dmitshur
Copy link
Member

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.

@maja42
Copy link
Author

maja42 commented Jan 14, 2019

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?

@dmitshur
Copy link
Member

dmitshur commented Jan 15, 2019

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants