-
Notifications
You must be signed in to change notification settings - Fork 17.9k
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
x/mobile: Cannot use GL calls inside Go library #12649
Comments
I thought the golang.org/x/mobile/gl package was tightly coupled with golang.org/x/mobile/app which bind apps don't depend on. I thought so because most gl calls are implemented by calling the enqueue (https://github.com/golang/mobile/blob/master/gl/work.go#L54) and DoWork ( https://github.com/golang/mobile/blob/master/gl/work.go#L80) is what's interacting with the enqueued data. The comment indicates it should be used by golang.org/x/mobile/app. If my guess is right, the doc needs to be clear about its usage. |
To use the GL package, something needs to start a locked OS thread processing GL events. It's relatively straightforward code if you already have a valid GL context loaded onto the current OS thread, otherwise it can be quite difficult. Once we have sorted out how to represent contexts (hopefully in the next week), I hope we can provide an easy way to use the GL package without the x/mobile/app. |
This would be great. I think that being able to transfer all your GL commands in Go library would be a common scenario. I would expect most people to use Java for the foundation of the application in cases when overlays, ads, and precise control over styles and manifest are desired and would use the Go library for performance critical tasks. (Vector, Graphics, Collision libraries). It would be also nice to have a more detailed documentation on the threading model that is currently used. For me personally it is not quite clear on which thread are Go functions, that have been invoked from JNI, executed. Is it always the same thread, could it be a different one each time? Is the same go routine reused or a new one per call? |
I was thinking about this and I believe it is much easier to achieve this now with the introduction of the I did some experimentations in making direct GL calls accessible from Java and it seemed to work, when used from the GLSurfaceView.Renderer methods, which makes me believe that the same thread is used in the Go-side when doing JNI. I could not find the later documented anywhere, however, so I could have just been lucky. |
Hi,
I have a Java Android application that uses a Go library to do some OpenGL rendering. I have configured something similar to the bind example.
I have a Go library that contains functions that execute some GL calls. In the Java app, I have a GLSurfaceView and inside the renderer I call to the Go library, however nothing gets rendered.
Furthermore, my phone would freeze up almost totally at times, at which point I need to power off the screen, turn it on, unlock the app and shut it down through recent apps option.
My Go code looks as follows:
and my Renderer class looks as follows:
The "Initializing: Hello World" is printed to LogCat but rendering does not occur. If I replace all the
Lib
calls with the code they represent, then I get a proper render to the screen.I am using the following tools:
Is there something special that I need to do to have all my OpenGL calls be managed by the Go library? I feel that something thread-related has changed since Go 1.5 Dev, where the same scenario would work.
Regards,
Momchil Atanasov
The text was updated successfully, but these errors were encountered: