Combined with the outstanding shiny CLs and prebuilt ANGLE dlls in the
right place, this makes it possible to run example/basic on a windows
machine.
Eventually this shiny backend will also replace the app package's
custom darwin_amd64 and linux_x11 backends.
For golang/go#9306
Change-Id: Ia4bf9a85b9d903d79cee36abb470a0ad57f09f36
Reviewed-on: https://go-review.googlesource.com/17777
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
Also move the initialization of glctx to an init function, removing
the data race mentioned in golang/go#12718. (Unfortunately the data
race is not the cause of the bug.)
Change-Id: If5f1fd7755d5645cf25ccc780ee8d138011c8f10
Reviewed-on: https://go-review.googlesource.com/15460
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>
More than a name change, the painting model changes so that the app, not
the library, is responsible for driving painting. If the app is
animating and wants paint events at 60 Hz, it has to ask for that. If
the app is not animating and doesn't need to update its screen, it
shouldn't get any paint events.
Plenty of TODOs, and this CL doesn't get us to a perfect place, but it
is a checkpoint along the way.
The darwin_*.go code changes were minimal. I don't even have a Mac or
iOS device to test that this even builds. Even so, the TODOs about not
sending paint.Events unconditionally are important TODOs. That's the
whole point of switching to this model. I'll leave the actual
implementation to you (crawshaw).
Out of all the example apps, the change to example/network/main.go is
probably the most interesting.
It seems like there ought to be some way to reduce the copy/paste
between all of the example app code, but I'll leave that for future CLs.
Change-Id: I17e11c06174110c68e17f7183b2d8af19b6a170e
Reviewed-on: https://go-review.googlesource.com/14300
Reviewed-by: David Crawshaw <crawshaw@golang.org>
While I'm here, make pixelsPerPt local on android and darwin/amd64.
The one place where it's global is darwin/arm, which has another
similar global (screenScale).
Change-Id: I5897e7e5341afca1976fdf0215fb4f6fe2f411be
Reviewed-on: https://go-review.googlesource.com/13446
Reviewed-by: Nigel Tao <nigeltao@golang.org>
This CL fixes two bugs in the existing app implementation on android.
The first, is it assumed a single NativeActivity instance is created
per process. This is not true. If you open an app, hit the back
button, then open it again, the original activity is destroyed and a
new one is created. So only call main.main in the first onCreate.
The second bug has to do with window lifetimes. Previously we only
processed GL work while the window existed, as part of a paint cycle.
This missed GL events called as part of a lifecycle downgrade when
the window was destroyed. (I.e. the contents of onStop.) This CL
fixes this by making the main android event processing loop last for
the life of the process, not the window.
Fixesgolang/go#11804.
Change-Id: Ia03e464aab5bc10ba75564b7ca11054515cda011
Reviewed-on: https://go-review.googlesource.com/12533
Reviewed-by: Nigel Tao <nigeltao@golang.org>
The gl package is not safe for concurrent use.
Change-Id: Ib0e7908746ea3a6520b2ce2f5d8aa7233ab2642c
Reviewed-on: https://go-review.googlesource.com/12165
Reviewed-by: David Crawshaw <crawshaw@golang.org>
If a frame draw cycle does not end in a blocking GL call,
then the app package may process the <-endDraw before the
final <-gl.WorkAvailable, meaning some GL calls miss the
frame.
So we make sure the final GL call for a frame is blocking.
Fixesgolang/go#11696.
Fixesgolang/go#10688.
Change-Id: I39772a3308c98947b1f0838ad58d1d406a711e7f
Reviewed-on: https://go-review.googlesource.com/12123
Reviewed-by: Nigel Tao <nigeltao@golang.org>
Package app contains some logic that we want to share with
gobind-based libraries. So move it to a new internal package
that both can import.
Long term the log changes should be in the standard library,
but the Go tree is currently frozen.
Fixesgolang/go#11630.
Change-Id: I9ff622fc499bf255bce18df23cb68b03f667947f
Reviewed-on: https://go-review.googlesource.com/11981
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
This does not break the dependency on the app package's AndroidContext
for loading assets on android. A potential answer for gobind-based
apps: add a SetAndroidContext method to app.Context. But I'll explore
that separately after the long weekend.
Change-Id: I812f899740e288c379eee7900f42d9d53926d4ce
Reviewed-on: https://go-review.googlesource.com/11675
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
Move runtime.LockOSThread from the portable Main to the
platform-specific android main. For darwin, calling LockOSThread in
Main is too late, there has been enough time for the goroutine
calling it to jump off the initial OS thread. For darwin we call
LockOSThread from an init function, which the runtime keeps on the
first thread. For Android we call LockOSThread only to maintain the
thread-local storage for the GL context that is created later, so
it is safe to call it from func main.
Also remove TODOs about starting a gobind app on Android, which
will be simplified in a followup CL.
Tested on darwin/amd64 and android. Not tested on X11.
Change-Id: I34c56abf8b1292959d4d508bfade287d196c0380
Reviewed-on: https://go-review.googlesource.com/11653
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>
Config provides a way to concurrently access Width and Height.
Register provides a way for packages to run code on app state change
without plumbing changes all the way to the process main function.
This is motivated by gl/glutil.Image which needs to rebuild its
textures on start/stop and can be deeply nested.
(See golang.org/cl/9707 for the followup.)
Tested manually on android and darwin/amd64. Doing this kind makes it
clear any CL modifying this code needs a lot of manual testing right
now, so some kind of trybot support is something I'm going to
prioritise.
Fixesgolang/go#10686Fixesgolang/go#10461Fixesgolang/go#10442Fixesgolang/go#10226
Updates golang/go#10327
Change-Id: I2882ebf3995b6ed857cda823e94fbb17c54b43a8
Reviewed-on: https://go-review.googlesource.com/9708
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
The State can be used in the Start callback (and lazily-initialized
packages) instead of JavaInit. This stores a reference to the
android.context.Context for the (future) keyboard package and for
setting TMPDIR.
Second attempt at https://golang.org/cl/4400.
Change-Id: I673997b26ab25ce5140cb31950593d8c6dbd9c51
Reviewed-on: https://go-review.googlesource.com/5555
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
They don't make sense for other platforms yet.
See golang/go#9603
Change-Id: I2ed269a00b1e1961aadf0a47fc95bbe3cd230113
Reviewed-on: https://go-review.googlesource.com/2902
Reviewed-by: David Crawshaw <crawshaw@golang.org>
Change-Id: If8ea6aaf2fb2c62eaf4119526a8bb46b8a84b982
Reviewed-on: https://go-review.googlesource.com/1881
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
Missing many features (like event processing). This is
just enough to get example/basic working.
LGTM=nigeltao
R=golang-codereviews, capnm9, bryanturley, nigeltao, crawshaw
CC=golang-codereviews
https://golang.org/cl/131030043
This is the minimum amount of machinery necessary to get
libgojni.so loading and callable from an Android App.
To keep impact on the Go runtime small, we construct an
auxv array here from /proc/self/auxv.
LGTM=minux, adonovan
R=adonovan, golang-codereviews, minux, bradfitz
CC=golang-codereviews
https://golang.org/cl/107500043
David Crawshaw
Nigel Tao
Hyang-Ah Hana Kim
Pierre Roullon
David Crawshaw
Andrew Gerrand