Make all our package sources use Go 1.17 gofmt format
(adding //go:build lines).
Not strictly necessary but will avoid spurious changes
as files are edited.
Part of //go:build change (#41184).
See https://golang.org/design/draft-gobuild
Change-Id: I30822eb504168b037ed3ec0f7759da1f41251f52
Reviewed-on: https://go-review.googlesource.com/c/mobile/+/294374
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
Reviewed-by: Jason A. Donenfeld <Jason@zx2c4.com>
The OpenGL C function glTexImage2D has the following signature:
void glTexImage2D(GLenum target,
GLint level,
GLint internalFormat,
GLsizei width,
GLsizei height,
GLint border,
GLenum format,
GLenum type,
const GLvoid * data);
However, the corresponding Context.TexImage2D method in package gl
does not include the internalFormat parameter, and use the format
argument instead. That's ok for many texture formats; for example,
RGBA textures have both format and internalFormat set to GL_RGBA.
But not always. In particular, OpenGL ES 3 allows the use of sRGB
encoded textures by specifying GL_SRGB8_ALPHA8 as internalFormat,
but keeping GL_RGBA as format.
Add the internalFormat to the Context package. This is unfortunately
a breaking change, but adding a new function ("glTexImage2D2"?) to
Context is too ugly for a parameter that should have been there all
along. (Adding a new method to the Context interface is technically
also a breaking change, but I don't expect that there are any
external implementers of the interface).
Change-Id: I12a45a34f604e51cb1be26aed906025ccfac533a
Reviewed-on: https://go-review.googlesource.com/133155
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>
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>
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>
