The 3:4 aspect ratio is more phone-like than the 1:1 400x400.
Change-Id: Ifbc800b853159ea9eb4f255cb0acad2b34996ce6
Reviewed-on: https://go-review.googlesource.com/24143
Reviewed-by: David Crawshaw <crawshaw@golang.org>
forked from https://golang.org/cl/20434
- added app/internal/callfn package update.
- changed hashes.go because -for some reason- the generated hashes don't match.
- build_androidapp.go had to be changed to deal with openal package.
Fixesgolang/go#10743
Change-Id: Iaa3f55d80c5fd184338d27832dc5c90cb772bd6a
Reviewed-on: https://go-review.googlesource.com/20707
Reviewed-by: David Crawshaw <crawshaw@golang.org>
Reviewed-by: Elias Naur <elias.naur@gmail.com>
Native activity callback onInputQueueCreated does not attach
a looper to the input queue within android.c. Various examples
of first detaching looper on the web are based around use of
native_app_glue_code which does attach a looper before passing
on to user callback.
Calling detachLooper pre-5.0 results in a crash. I didn't track
down exact source for this but code that likely made it's way
into 5.0 given the time frame can be seen to show a recast of
and iter over size() of a container.
This possibly explains the lack of crashing for 5.0+ instead of
potentially referencing a null pointer pre-5.0.
Fixesgolang/go#13741
Change-Id: Ie04de9f34436a95c456a56b34f1ca7e6adc00b09
Reviewed-on: https://go-review.googlesource.com/20145
Reviewed-by: Nigel Tao <nigeltao@golang.org>
Much like the recent change for OS X, this puts the Go paint loop in
control of drawing onto the screen.
Change-Id: I37321e4bb58869d4c7cafc51951ea64e540d536b
Reviewed-on: https://go-review.googlesource.com/15611
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
OpenGL ES is not installed by default on linux distributions, which
can lead to a cryptic error. Add a comment after the #include
mentioning what packages contain OpenGL ES on Ubuntu, which is
helpfully printed in the error message. For example:
$ go build golang.org/x/mobile/example/basic
# golang.org/x/mobile/gl
In file included from ../../mobile/gl/work.go:21:0:
work.h:6:117: fatal error: GLES2/gl2.h: No such file or directory
#include <GLES2/gl2.h> // install on Ubuntu with: sudo apt-get install libegl1-mesa-dev libgles2-mesa-dev libx11-dev
Change-Id: Ia7ba583cee4dfdeed408f582b29da90de9a4fab3
Reviewed-on: https://go-review.googlesource.com/18058
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
improved a problem that continues to maintain a touch-ID
that must be discarded by 'touchesCanceled' event.
Fixesgolang/go#13435
Change-Id: I13635255e5317bba2202bf7a8d2dd957f7824d0a
Reviewed-on: https://go-review.googlesource.com/18180
Reviewed-by: David Crawshaw <crawshaw@golang.org>
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>
Fixesgolang/go#12911
Note: the x11 support seems outdated in general compared to
android, darwin versions.
Change-Id: I2a80215c62b8c3cf87c5eb054184fea10819abc9
Reviewed-on: https://go-review.googlesource.com/15790
Reviewed-by: David Crawshaw <crawshaw@golang.org>
A paint.Event now has an External field. Whenever a paint event is
sent by the x/mobile/app package, it is marked as external so users
with an active paint loop can ignore them.
Implemented on OS X and Android, with examples updated.
Change-Id: Ibee8d65625c8818ff954936be48257ad30daa147
Reviewed-on: https://go-review.googlesource.com/15480
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
The CGL display link is a timer keyed on screen refresh rate. It made
sense to use it when the app package controlled the screen paint
cycle. Now that the paint cycle control has moved to the user, and
given that we have always made the equivalent of Publish block until
vsync, it is just complicating matters. The user can come up with
their own timer, and safely dedicate a goroutine to event handling
that paints as fast as it likes without running over the vsync time.
A version of this for iOS will follow (giving up on the timer provided
by GLKViewController) when I get my iOS setup working again.
(Note there is also a bug in the way drawgl works presently. This CL
doesn't fix the bug, but is a first step in untangling the draw loop
so I can fix it.)
Change-Id: I464d5b15f018527d98b792026fb3899681f24e4b
Reviewed-on: https://go-review.googlesource.com/15470
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>
The package-level OpenGL calls in golang.org/x/mobile/gl were removed.
This change fixes testapp to use their replacement.
This change also moves the location of the test taps to be further away
from the top of the screen. On my phone (running L), a tap at 50,60 is
opens the draggy menu thing that Android has and the running app doesn't
see it (which causes the test to not complete).
Change-Id: I679c9b61919a332f9b4a53e0950ff96f6aefbbbb
Reviewed-on: https://go-review.googlesource.com/15050
Reviewed-by: David Crawshaw <crawshaw@golang.org>
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>
We now have one such goroutine for the life of the process, not one per
onInputQueueCreated call (e.g. whenever the app re-gains visibility).
Also use ALooper_wake instead of rolling our own os.Pipe.
Change-Id: I4fa045972289144e083033f2e243cac65f35ee46
Reviewed-on: https://go-review.googlesource.com/14670
Reviewed-by: David Crawshaw <crawshaw@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>
Previously, we did:
for {
processEvents() // Process any pending Android input events.
select { // Select Go events (channel send/receives).
etc
}
}
The problem was that if you were blocked on the select because there
were no incoming Go events, then you weren't reading new input events,
and the UI could block indefinitely.
After this CL, input events are processed in a dedicated goroutine,
where it's fine for
for C.AInputQueue_getEvent(q, &e) >= 0 { etc }
to block, and the main loop deals only with Go channels:
for {
select {
etc
}
}
Change-Id: I8ec27a40e220b1d95a6b6fc14347a59833ccfdc8
Reviewed-on: https://go-review.googlesource.com/14500
Reviewed-by: David Crawshaw <crawshaw@golang.org>
Replace the direct access to JavaVM* and the global android Context
instance with a function responsible for running attached correctly
to the JVM. This saves having to replicate the logic for attaching an
OS thread to the JVM. While here, check for any unhandled Java
exceptions.
This supersedes cl/11812.
Change-Id: Ic9291fe64083d2bd983c4f8e309941b9c47d60c2
Reviewed-on: https://go-review.googlesource.com/14162
Reviewed-by: Nigel Tao <nigeltao@golang.org>
This is only the first half of physical key event mapping. The
modifiers and hardware key codes will be in a followup CL. I'm
splitting this out because it covers two other parts of the problem:
first is maintaining a JNIEnv pointer for the main routine, the
second is access to the Android unicode key map. The NDK does not have
a method to give us the key mapping, so we get to it via
GoNativeActivity.
Tested with a USB keyboard. I'll attempt an abd-based unit test later,
but I suspect it will be difficult to set a device ID.
Change-Id: Ie93700d1f2a5d382a9b17cdd668cb4acaa6e4bcc
Reviewed-on: https://go-review.googlesource.com/13649
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
Also catches any bugs that cause painting to lock up after
rotation (of which there have been many).
Change-Id: I3783030efd2c342afebf2b861e9e9dc32e96f659
Reviewed-on: https://go-review.googlesource.com/13616
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
Ran into this while working on keyboard events. I'm a little surprised
this hasn't been a problem so far -- my understanding of the NDK
functions for working with a NativeActivity is that the require you
hold a valid JNI context before calling them.
Change-Id: Ifd322ef5e8406df648d1a8f667e5ce08ffef954d
Reviewed-on: https://go-review.googlesource.com/13648
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
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>
When the generation number is bumped, the <-endPaint case will drop
any old paints. So if a new paint isn't sent to replace it, the app
locks up.
This is a bug that looks like it crept into cl/12533 just before it
was submitted. (Sorry.) I'm working on tests as part of adding
android orientation support.
Change-Id: I6b62bdc6774e090b67a5577c3eae7355e3937894
Reviewed-on: https://go-review.googlesource.com/13445
Reviewed-by: Nigel Tao <nigeltao@golang.org>
There's no need for more than one Android .go file.
Change-Id: I75f5ced5680088b0ddbe5c700981b9a595d9e321
Reviewed-on: https://go-review.googlesource.com/13343
Reviewed-by: David Crawshaw <crawshaw@golang.org>
Higher-level widget or animation libraries should probably work in
geom.Pt, but pixels instead of (1/72s of) inches seems a better fit for
lower-level event libraries. Needlessly converting from (float32) pixels
to (float32) points and back can be lossy and lead to off-by-one errors.
Change-Id: I68102e36f2574b07b44c6a1b7281f4f27f9174cf
Reviewed-on: https://go-review.googlesource.com/13002
Reviewed-by: David Crawshaw <crawshaw@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>
Also add a few missing codes.
Change-Id: I26b6db31067c67107fe4db142ec9f48ff13cc53e
Reviewed-on: https://go-review.googlesource.com/12536
Reviewed-by: Nigel Tao <nigeltao@golang.org>
The property was only introduced in 10.10, and doesn't offer us
anything more than what the method gives us.
Fixesgolang/go#11827.
Change-Id: I5a9f9b068b9f18acc85a68a37dae11f19df686a1
Reviewed-on: https://go-review.googlesource.com/12552
Reviewed-by: Andrey Petrov <shazow@gmail.com>
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
First cut of events from physical keyboards.
Simple darwin/amd64 implementation.
Change-Id: I6e9d0a253387c841864ca9845ee729ea4f7573c7
Reviewed-on: https://go-review.googlesource.com/11815
Reviewed-by: Nigel Tao <nigeltao@golang.org>
EGL is a poor source of window dimensions. On some fraction of
rotations, it reported the old dimensions. Switch to extracting the
data from ANativeWindow, which appears to be more reliable.
While here, plumb through orientation, and follow the recommendation
in the Android platform docs to block onNativeWindowRedrawNeeded
until the draw is complete.
Fixesgolang/go#11741.
Change-Id: I6b29b6a1e5743c612c9af2a8cce4260c5d7e9ca6
Reviewed-on: https://go-review.googlesource.com/12381
Reviewed-by: Nigel Tao <nigeltao@golang.org>
Nigel Tao
Hyang-Ah Hana Kim
Daniel Skinner
David Crawshaw
nobonobo
Shenghou Ma
Paul Hankin