shortcomings in the gl package and where it should be going.
Some background: the gl package is designed for GL ES 2.0 on
Android/iOS. It also works on OS X and Linux/X11 for the purpose of
development (and eventually testing). This means you can write an app
designed for android, and compile it with the normal go command to get
a desktop binary. These desktop targets are and should remain a
secondary goal for now.
In cl/8793 there is a proposal for new build tag: js. This increases
the number of ways to configure the gl package, right now it selects
entirely on GOOS and GOARCH. I would like to avoid adding a build tag
mechanism because I think by solving another limit of the gl package
we can get to a place where backends for the GL package can be
registered by external packages.
There are two limits of the gl package I would like to address before
1.5 is released.
The first is that using it requires an understanding the
implementation details of goroutines. Each GL call maps directly onto
the C function which needs the GL context to be in thread-local
storage. This means careful use of runtime.LockOSThread is necessary
to use the package correctly.
The second is it will be very hard to add windows support without
importing code under other copyright licenses and generating code.
These are completely acceptable copyrights, but their existence
complicates vendoring the mobile package, which I will want to
encourage when 1.5 is released. More generally: our only configuration
tool is #ifdef in cgo headers. If a software-based GL existed that
allowed us to write a good testing package, it would be very difficult
What I'm exploring is introducing a gl.Context interface with the
current functions hanging off it as methods. The gl.Context exported
by the package will forward function calls to a goroutine locked to an
OS thread, which will make the C calls. This removes the need to
understand goroutine implementation details to use the package.
Any performance lost due to the indirection can be recovered by
batching calls across the cgo boundary (each C function call in a
modern GL implementation appears to do little more than drop a task on
an asynchronous queue, so most of the cost of the function calls is
the cgo overhead).
There are several points I'm not sure about yet: does the gl package
continue to offer package-level functions, or export a package
variable containing the default gl.Context? Either way I intend to
change the function signatures very little, as I think there is a lot
of value in keeping the functions close to the C headers. OpenGL
knowledge is hard to come by and I don't want people to have to learn
even more than they have acquired elsewhere to use it.
You received this message because you are subscribed to the Google Groups "golang-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to firstname.lastname@example.org.
For more options, visit https://groups.google.com/d/optout.