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.
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:
Min / Compile / Target SDK Version: 16
Android Studio: 1.3.2
Go: go1.5.1 darwin/amd64
Mobile Gradle plugin: org.golang.mobile.bind:0.2.3 (I tried 0.2.2 as well)
Android Build Tools: 23.0.1
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.
The text was updated successfully, but these errors were encountered:
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 Context interface. I guess if it were possible for end-users to instantiate a Context instance that did direct GL calls internally (instead of adding them to a queue), it might work.
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.