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>
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>
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>
Also add a few missing codes.
Change-Id: I26b6db31067c67107fe4db142ec9f48ff13cc53e
Reviewed-on: https://go-review.googlesource.com/12536
Reviewed-by: Nigel Tao <nigeltao@golang.org>
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>
The full set of event.LifecycleStages are now plumbed through.
More user control over the window, in particular it:
- takes focus correctly on start
- can now be closed and minimized
- can be hidden (allowing testing of LifecycleStageAlive)
Flickering during resize has been eliminated by triggering draws from
a second thread. This encouraged the introduction of a dedicated draw
loop in Go, which makes responsibility for GL calls a little more
like android/x11.
Change-Id: I63982f20bd4859601e2a27915f60f6c8083a176f
Reviewed-on: https://go-review.googlesource.com/11733
Reviewed-by: Nigel Tao <nigeltao@golang.org>
It is already done in our examples and is missing from the linux/x11
implementation. If memory serves this is just long-standing
debugging cruft.
Change-Id: I1919a8704b11502fe8f402e3840bc5a1cd8b16e3
Reviewed-on: https://go-review.googlesource.com/11655
Reviewed-by: Nigel Tao <nigeltao@golang.org>
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>
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>
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>
Still needs some geometry adjustments, coming in a followup CL.
Change-Id: If1298a0deef117ee635db1af78fb743a60a8c8d5
Reviewed-on: https://go-review.googlesource.com/5480
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
