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

x/mobile: Cannot use GL calls inside Go library #12649

mokiat opened this issue Sep 16, 2015 · 4 comments

x/mobile: Cannot use GL calls inside Go library #12649

mokiat opened this issue Sep 16, 2015 · 4 comments
mobile Android, iOS, and x/mobile


Copy link

mokiat commented Sep 16, 2015


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:

package lib

import (

func OnCreate() {
    gl.ClearColor(0.2, 0.2, 0.6, 1.0)

func OnChanged(width, height int) {
    gl.Viewport(0, 0, width, height)

func OnDraw() {

func GetString() string {
    return "Hello World"

and my Renderer class looks as follows:

package com.demotexbg.thugpigeon;

import android.opengl.GLES20;
import android.opengl.GLSurfaceView;

import javax.microedition.khronos.egl.EGLConfig;
import javax.microedition.khronos.opengles.GL10;

import go.lib.Lib;

public class GameActivityRenderer implements GLSurfaceView.Renderer {

    public void onSurfaceCreated(GL10 gl, EGLConfig config) {
        System.out.println("Initializing: " + Lib.GetString());

    public void onSurfaceChanged(GL10 gl, int width, int height) {
        Lib.OnChanged(width, height);

    public void onDrawFrame(GL10 gl) {


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
  • Java: 1.7
  • Android Studio: 1.3.2
  • Go: go1.5.1 darwin/amd64
  • Mobile Gradle plugin: (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.

Momchil Atanasov

@hyangah hyangah added this to the Unreleased milestone Sep 16, 2015
Copy link

hyangah commented Sep 16, 2015

I thought the package was tightly coupled with which bind apps don't depend on.

/cc @crawshaw @nigeltao

I thought so because most gl calls are implemented by calling the enqueue ( and DoWork ( is what's interacting with the enqueued data. The comment indicates it should be used by

If my guess is right, the doc needs to be clear about its usage.
It would be nice if gobind apps can do gl from go side.

Copy link

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.

Copy link

mokiat commented Sep 17, 2015

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?

Copy link

mokiat commented Oct 19, 2015

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.

@gopherbot gopherbot added the mobile Android, iOS, and x/mobile label Jul 20, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
mobile Android, iOS, and x/mobile
None yet

No branches or pull requests

4 participants