Make all our package sources use Go 1.17 gofmt format
(adding //go:build lines).
Not strictly necessary but will avoid spurious changes
as files are edited.
Part of //go:build change (#41184).
See https://golang.org/design/draft-gobuild
Change-Id: I30822eb504168b037ed3ec0f7759da1f41251f52
Reviewed-on: https://go-review.googlesource.com/c/mobile/+/294374
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
Reviewed-by: Jason A. Donenfeld <Jason@zx2c4.com>
Update the build constraints so that OpenGL is used both on
macOS AMD64 and ARM64, while OpenGL ES is used on iOS.
This fixes the build on M1 Macs.
For golang/go#43237.
Change-Id: Iad2d406eaf0ddbe72f221f497dd074ad0b22015e
Reviewed-on: https://go-review.googlesource.com/c/mobile/+/278779
Trust: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Hajime Hoshi <hajimehoshi@gmail.com>
Now `gomobile bind -target ios` tries to compile a lib with
`darwin/arm`, `darwin/arm64`, and `darwin/amd64`. In the last
case, a tag `ios` is always added. In `x/mobile/gl`, the last case
`darwin/arm64` was not considered well and causes a compile error.
This CL fixes this compile error.
Fixesgolang/go#16067
Change-Id: I56be73f373d9985c067a07e5084fa6b9f1ef76a0
Reviewed-on: https://go-review.googlesource.com/24140
Reviewed-by: David Crawshaw <crawshaw@golang.org>
This CL covers the basic structure for supporting ES 3.0 where the
platform provides it, and includes one ES 3.0 function as a
proof-of-concept. The rest of the functions and constant values will
follow in later CLs.
ES 3.0 is available everywhere except Android older than
version 4.3, approximately half of Android devices today:
https://developer.android.com/about/dashboards/index.html#OpenGL
Change-Id: Ief7714131227c447a0c603dadad0bd5285999bb3
Reviewed-on: https://go-review.googlesource.com/23821
Reviewed-by: Nigel Tao <nigeltao@golang.org>
Each GL context is used serially, so make the map context-specific.
For golang/go#9306
Change-Id: Ic8261795312bf404f765a9ae8969468f4d170dae
Reviewed-on: https://go-review.googlesource.com/17772
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
This allows a subsequent CL to introduce windows support by directly
calling an ANGLE dll.
For golang/go#9306
Change-Id: I7dbe8f2b77b9e2c744f0d848f716ee4448916fe7
Reviewed-on: https://go-review.googlesource.com/17674
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
It is an error to use a gl.Context concurrently. (Each Context
contains a state machine, so there is no way this can work.)
Up until now only the GL driver could report such a misuse, and
it generally does a poor job of it. Our command buffer adds some
small oppertunity for the race detector to help, but it makes it
harder to debug other kinds of driver crashes, so it is worth
disabling in debug mode.
To make it easy, compiling with -tags gldebug now inserts an
explicit check that there are no other active GL calls outstanding.
Adding something like:
go func() {
for {
glctx.GetInteger(gl.ALPHA_BITS)
}
}()
to x/mobile/example/basic now reliably crashes when compiled
with -tags gldebug, providing a stack trace that includes both
misbehaving goroutines.
Change-Id: I3d85d94220bca2a15eaf2742f13b44db1f3428bf
Reviewed-on: https://go-review.googlesource.com/15180
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
All OpenGL functions are now methods on a Context interface. The
gl.Context matches the one loaded into thread-local storage in C.
For mobile apps, the context is owned by an app.App. For now, it is
provided through the events channel on a lifecycle event. Long-term,
it should probably be available by a method on app.App, but this is
inherently racey with our current use of a channel to deliver events.
Shiny-based programs will have a gl.Context associated with a each
shiny.Window. The expectation is each Window will have different
contexts, allowing them to draw separately.
Change-Id: Ie09986fb74e493129f2ea542a151c95c6fa29812
Reviewed-on: https://go-review.googlesource.com/13431
Reviewed-by: Nigel Tao <nigeltao@golang.org>
This change will break Darwin. I have only built and tested this on
desktop linux and Android linux. A follow-up CL will fix Darwin.
Currently, OpenGL gets its own thread, and UI C code (e.g. the Android
event loop, or the X11 event loop) gets its own thread. This relies on
multiple system-provided UI-related C libraries working nicely together,
even when running on different threads. Keeping all the C code on the
one thread seems more sound.
As side-effects:
- In package app/debug, DrawFPS now takes an explicit Config.
- In package app, some callbacks now take an explicit Config.
- In package exp/sprite, Render now takes an explicit Config.
- In package event, there are new events (Config, Draw, Lifecycle),
and an event filter mechanism to replace multiple app Callbacks.
- In package geom, the deprecated Width, Height and PixelsPerPt global
variables were removed in favor of an event.Config that is
explicitly passed around (and does not require mutex-locking).
Converting a geom.Pt to pixels now requires passing a pixelsPerPt.
- In package gl, the Do, Start and Stop functions are removed, as well
as the need to call Start in its own goroutine. There is no longer a
separate GL thread. Instead, package app explicitly performs any GL
work (gl.DoWork) when some is available (gl.WorkAvailable).
- In package gl/glutil, Image.Draw now takes an explicit Config.
Callbacks are no longer executed on 'the UI thread'.
Changing the app programming model from callbacks to events (since a
channel of events works with select) will be a follow-up change.
Change-Id: Id9865cd9ee1c45a98c613e9021a63c17226a64b1
Reviewed-on: https://go-review.googlesource.com/11351
Reviewed-by: David Crawshaw <crawshaw@golang.org>
All GL function calls fill out a C.struct_fnargs and drop it on the
work queue. The Start function drains the work queue and hands
over a batch of calls to C.process which runs them. This allows
multiple GL calls to be executed in a single cgo call.
A GL call is marked as blocking if it returns a value, or if it
takes a Go pointer. In this case the call will not return until
C.process sends a value on the retvalue channel.
Change-Id: I4c76b2a8ad55f57b0c98d200d0fb708d4634e042
Reviewed-on: https://go-review.googlesource.com/10452
Reviewed-by: Nigel Tao <nigeltao@golang.org>
