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>
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>
Change-Id: Ie04a58ac090d8916463586b5fadb14c5539a21dd
Reviewed-on: https://go-review.googlesource.com/11640
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
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>
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>
