The underlying implementation was not enabling the sensors on a
particular sender even though the Enable signature accepts different
instances of Sender to enable.
Consider the following program:
type A struct{}
func (a A) Send(ev interface{}) {}
type B struct{}
func (b B) Send(ev interface{}) {}
sensor.Enable(A{}, sensor.Gyroscope, time.Millisecond)
sensor.Enable(B{}, sensor.Accelerometer, time.Millisecond)
is going to compile but only A will be notified when there are new
gyroscope and accelerometer events.
In order to improve the misleading APIs, this CL introduces a
Notify function that users can register a Sender implementation to
listen the changes. If set nil, the sensor package will keep
reading the events but will won't notify.
sensor.Notify(A{})
sensor.Enable(sensor.Gyroscope, time.Millisecond)
sensor.Enable(sensor.Accelerometer, time.Millisecond)
Change-Id: I25e43349e4ae682930baa2d32430f46f24b588b7
Reviewed-on: https://go-review.googlesource.com/15650
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
Naked returns must be used for self-documentary reasons. In this
unexported package, it is not useful to name return values.
The change has been contributed on a previous CL but I don't know
what happened, it should have been lost on a bad merge.
Change-Id: I6cb9c3a58ad397aeb646f3e57e482628fe31ca31
Reviewed-on: https://go-review.googlesource.com/15658
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
readEvents never return an error, readSignal should not have an
error field.
Change-Id: I9566a6905ee678599fdad18f85ae55d1fdc16cc1
Reviewed-on: https://go-review.googlesource.com/15550
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
Several notices, notes and questions have become obsolete when
CL/15438 is merged. Removing the TODOs pointing to the bug explained
in CL/15438's description.
Change-Id: I8a94507a6d0aa507a58be451336eba36dd383d64
Reviewed-on: https://go-review.googlesource.com/15551
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
The init signal's job could be done at the top of the proxying
goroutine.
Change-Id: Icb907946a679d3eca6bec5e12adeb2bedc0908f0
Reviewed-on: https://go-review.googlesource.com/15490
Reviewed-by: David Crawshaw <crawshaw@golang.org>
Only the loopers allocated with ALooper_acquire are releasable. We are
depending on the looper associated to the thread which will be
automatically released when the thread is being terminated.
Trying to re-release a looper makes the app crash with segfault.
Change-Id: Ib80549de01f5f44143752c13a82b6b4a2ab5610e
Reviewed-on: https://go-review.googlesource.com/15491
Reviewed-by: David Crawshaw <crawshaw@golang.org>
The sensor package had a deadlock case if it started to poll the
events but all sensors have been disabled on the underlying ALooper.
Consider the following program:
app.Main(func(a app.App) {
sensor.Enable(a, sensor.Gyroscope, time.Millisecond)
go func() {
time.Sleep(5 * time.Second)
sensor.Disable(sensor.Gyroscope)
time.Sleep(2 * time.Second)
sensor.Enable(a, sensor.Gyroscope, time.Millisecond)
}()
for e := range a.Events() {
case sensor.Event:
//...
}
The initial Enable will enable the gyroscope and start polling events
from the ALooper. After 5 seconds, the gyroscope will be disabled.
ALooper_pollAll(-1, NULL, &events, NULL)
will block indefinately because there are no events will be
available until another sensor is enabled.
After 2 seconds, we will attempt to enable the gyroscope again. But,
the underlying thread will be blocked at pollAll and won't be able
to make the sensor enabling call on the same thread.
In order to overcome this deadlock case, this thread introduces a
hard timeout limit during polling. If timeout occurs, the looper
thread will be unblocked and select{} statement will be able to
handle {enable,disable,close}Signal cases.
Fixesgolang/go#12501.
Change-Id: I35efa2e29057ca37f8ac0f38be8dc59c9b8262b3
Reviewed-on: https://go-review.googlesource.com/15438
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>
It is now the user's job to track the lifetime of a glutil.Image
relative to a (currently implicit, soon to be explicit) GL context.
This is an attempt to move glutil.Image closer to the model for
buffers and textures in shiny. Long-term, I would like to adopt that
model, and this is a step in that direction. It also makes the
introduction of *gl.Context possible, so this is a pre-req for
cl/13431.
Change-Id: I8e6855211b3e67c97d5831c5c4e443e857c83d50
Reviewed-on: https://go-review.googlesource.com/14795
Reviewed-by: Nigel Tao <nigeltao@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>
The manager type is not required, because the APIs don't allow
more than one event sources as they used to. In this CL, I am
flattening out the underlying implementations by removing the
manager type.
Change-Id: I3b606ac160b9cecd85cb657e3df1d7d789604764
Reviewed-on: https://go-review.googlesource.com/14293
Reviewed-by: Nigel Tao <nigeltao@golang.org>
The former Reader inspired APIs were designed to timeout if no events
occur after an excessive amount of time. As we switch to the app
event based model, timing out is not required. We can block on
pollAll forever until new events arrive.
Change-Id: I086fc908ebfe6ae9bd96ce9199636ad0242bbec5
Reviewed-on: https://go-review.googlesource.com/14223
Reviewed-by: Nigel Tao <nigeltao@golang.org>
The CL provides accelerometer events only, upcoming CLs will add
support for gyroscope and magnetometer.
Change-Id: Ib5629ca7c49c9dfc8ca533fe7acde371efc102b2
Reviewed-on: https://go-review.googlesource.com/14036
Reviewed-by: Nigel Tao <nigeltao@golang.org>
We are also limiting the number of sensor managers to one.
The application provide sensor events to third-party packages
by consuming them in the main.
An application will be able to consume the sensor events similar
to the other events.
package main
func main() {
app.Main(func(a app.App) {
// enables the accelerometer
sensor.Enable(a, sensor.Accelerometer, 100*time.Millisecond)
var sz size.Event
for e := range a.Events() {
switch e := app.Filter(e).(type) {
case sensor.Event:
log.Println(e)
}
}
})
}
Change-Id: Iaad1c59f8d2322c7620df62ed9b9283c91746fa8
Reviewed-on: https://go-review.googlesource.com/13983
Reviewed-by: Nigel Tao <nigeltao@golang.org>
Also remove an unnecessary constant type conversion.
Change-Id: Iff466553fac450bd531785f4fb4e2be97a991a52
Reviewed-on: https://go-review.googlesource.com/13715
Reviewed-by: Burcu Dogan <jbd@google.com>
Hoping to learn more so I can debug or replicate the darwin/amd64
builder failure, which is not creating a GL context.
Change-Id: I9f2fe54fbd9a072c65cd37c3b711554d4c71171f
Reviewed-on: https://go-review.googlesource.com/13693
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
There is no way to distinguish an unknown format from
Mono8 because Mono8 is zero. The current CL fixes this
issue by starting the format constants from iota + 1.
Change-Id: I8c709cdaff3bc46bcc15ab770cfcfd04c186034d
Reviewed-on: https://go-review.googlesource.com/12386
Reviewed-by: Burcu Dogan <jbd@google.com>
Embedding is more trouble than it's worth. For example, the image/draw
package will pick the slow code paths for an embedded *image.RGBA.
Change-Id: I64bd20a80814b838850950c05dd8257e5901aef7
Reviewed-on: https://go-review.googlesource.com/12567
Reviewed-by: David Crawshaw <crawshaw@golang.org>
This is done by moving app.Context to internal/mobileinit,
introducing mobileinit.SetCurrentContext and,
making bind/java depend on it.
TODO: check gomobile bind's proguard rule - context lookup
was implemented through reflection on android.app.AppGlobals class.
Change-Id: Ieb6ad503eeef8c2c1c5836a21c667938c5a701a2
Reviewed-on: https://go-review.googlesource.com/12279
Reviewed-by: David Crawshaw <crawshaw@golang.org>
There is currently one usage of "an" prior to "PCM". The indefinite
article usage prior to an acronym is determined by the
pronunciation of that acronym's first letter. If the pronunciation
starts with a consonant, "a" is used. If the pronunciation starts
with a vowel, "an" is used.
Usage
https://en.wikipedia.org/wiki/Pulse-code_modulation
Note that there is currently a correct usage in the same file on a
different line: "a PCM header"
Change-Id: Id7749d20722a5cc9b96ecfe466be66fe3c76ab2b
Reviewed-on: https://go-review.googlesource.com/12083
Reviewed-by: David Crawshaw <crawshaw@golang.org>
This CL reverts the changes made in golang/go#11299.
Allowing creation of multiple contexts break the case of multiple
third party packages depending on the al bindings. These packages
need to make sure that there is a valid current context or initiate
and make a context current. Packages racing to create and make a
context current is what we would like to avoid.
Therefore, al bindings will support only a single context that is
initiated during OpenDevice.
Fixesgolang/go#11385.
Change-Id: I662f70e49d12833a545005cf0724cc21f67bea09
Reviewed-on: https://go-review.googlesource.com/12001
Reviewed-by: Nigel Tao <nigeltao@golang.org>
Ever since we moved to a bitmap font instead of using freetype, the backing
image's dimensions are 43x9, not 50x12, and we might as well match. For
example, the output will be exactly 43x9 pixels at 72DPI, or 86x18 pixels at
144DPI, etc.
Change-Id: I99975cc780760b28b73fbf6d55befbe500f1a6e1
Reviewed-on: https://go-review.googlesource.com/11880
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
In the long term, a lot of this package should be removed in favor of the
golang.org/x/image/math/f32 package. The latter is the common location for
matrix types shared across graphics libraries. For example, the
golang.org/x/image/draw package refers to golang.org/x/image/math/f64.
Change-Id: I9d7ccd3cb35912e0d9dc5bd46c919516ea840340
Reviewed-on: https://go-review.googlesource.com/11856
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
Change-Id: Id71acfeb605995d8caf947d996a1375335410e08
Reviewed-on: https://go-review.googlesource.com/11668
Reviewed-by: David Crawshaw <crawshaw@golang.org>
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
This CL is a followup of CL/11315 where it is suggested to remove
Context pointer types from the signatures.
Change-Id: Ice68bfabad0e345f7d93102257a99402be8760b5
Reviewed-on: https://go-review.googlesource.com/11560
Reviewed-by: Nigel Tao <nigeltao@golang.org>
This means that there's only one adb log prefix that Go app developers
need to watch: GoLog.
Change-Id: I562566b92a7bba19f7c7a9cc71315bea02844db1
Reviewed-on: https://go-review.googlesource.com/11609
Reviewed-by: Burcu Dogan <jbd@google.com>
