Also add missing switch cases which cause a compiler warning on OS X.
They are unused so far.
Fixesgolang/go#16071
Change-Id: I5ced5a814a7abc956b0b0cdad211ecd69a54a95b
Reviewed-on: https://go-review.googlesource.com/24177
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
Nothing exciting, just exercising the layout of the functions.
Change-Id: I460fdc1c9596968bbdfdafe7d068ea393e0029ed
Reviewed-on: https://go-review.googlesource.com/24051
Reviewed-by: Nigel Tao <nigeltao@golang.org>
This CL covers the basic structure for supporting ES 3.0 where the
platform provides it, and includes one ES 3.0 function as a
proof-of-concept. The rest of the functions and constant values will
follow in later CLs.
ES 3.0 is available everywhere except Android older than
version 4.3, approximately half of Android devices today:
https://developer.android.com/about/dashboards/index.html#OpenGL
Change-Id: Ief7714131227c447a0c603dadad0bd5285999bb3
Reviewed-on: https://go-review.googlesource.com/23821
Reviewed-by: Nigel Tao <nigeltao@golang.org>
This allows a subsequent CL to introduce windows support by directly
calling an ANGLE dll.
For golang/go#9306
Change-Id: I7dbe8f2b77b9e2c744f0d848f716ee4448916fe7
Reviewed-on: https://go-review.googlesource.com/17674
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>
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>
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>
David Crawshaw
Hana Kim
Nigel Tao