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>
x11/gl is not thread-safe, so all x11/gl related API should be called
from one thread. There's already a dedicated thread for GL calls, so
move all x11 API calls to GL thread using gl.Do(...)
Fixesgolang/go#11066
Change-Id: If84a8d56e978ce30d7fbbc310740fcc794ce61d7
Reviewed-on: https://go-review.googlesource.com/10744
Reviewed-by: Nigel Tao <nigeltao@golang.org>
- Fix hangs on linux/x11. x11-related code remains outdated since
068a51c19, which seperates GL calls to dedicated thread. Update x11
code to work with GL thread.
- Fix bug on coordinate system. x11 has same coordinate system with
android, (0,0) on top-left.
Change-Id: I0b3ab97fd4842b1c9f730e1c90a5840f540fcb7a
Reviewed-on: https://go-review.googlesource.com/10623
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>
An example of how to handle multiple concurrent touches using this design:
var touched = map[event.TouchSequenceID]*Widget{}
func touch(t event.Touch) {
if t.Type == event.TouchStart {
if w := widgetAt(t.Loc); w != nil {
touched[t.ID] = w
}
}
if w, ok := touched[t.ID]; ok {
// move/scroll widget, etc
}
if t.Type == event.TouchEnd {
delete(touched, t.ID)
}
}
Change-Id: I79910ef30abe9a41bc0720783022b1af081fbd43
Reviewed-on: https://go-review.googlesource.com/1895
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
Reviewed-by: Burcu Dogan <jbd@google.com>
Reviewed-by: David Crawshaw <crawshaw@golang.org>
