x11.c refers to several types defined in Xlib headers, but did not
include those headers explicitly. As far as I can tell, it assumed
that they are indirectly included via egl.h — but that assumption
empirically does not always hold.
This fixes a build error on my machine. I'm not sure why it hasn't
shown up on the Go dashboard builders.
Change-Id: I70146c68ff7e4d32af63a5aa8d7a8e25445091c5
Reviewed-on: https://go-review.googlesource.com/c/exp/+/359695
Trust: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
The iconvg Go implementation started at golang.org/x/exp/shiny/iconvg in
2016, speaking a file format retroactively named FFV0 (File Format
Version 0). The github.com/google/iconvg/src/go/* packages were created
more recently in 2021 and will speak a revised format, FFV1.
The long term plan is for the github.com/... packages to *only* speak
FFV1. The golang.org/... package (this package) will continue to speak
FFV0 directly and will additionally delegate decoding FFV1 to the
github.com/... packages. FFV0 will be considered a deprecated experiment
(it was marked EXPERIMENTAL ever since its inception). See
https://github.com/google/iconvg/issues/4
This commit, which decodes FFV0 and encodes FFV1, lives in the
golang.org/... packages, since it involves FFV0. Testing it (beyond the
basic consistency checks in upgrade_test.go) lives in the github.com/...
packages, since that involves decoding FFV1. For example, some outputs
of the UpgradeToFileFormatVersion1 function (added by this commit) were
checked in as https://github.com/google/iconvg/commit/c98b08c
Change-Id: Ib5861ae97928cf31faf207b915568532e2624f09
Reviewed-on: https://go-review.googlesource.com/c/exp/+/332989
Trust: Nigel Tao <nigeltao@golang.org>
Reviewed-by: Andrew Gerrand <adg@golang.org>
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: Id0f07c94a24a65e20ea98a91dc18965e17f1b0ff
Reviewed-on: https://go-review.googlesource.com/c/exp/+/294418
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Jason A. Donenfeld <Jason@zx2c4.com>
Reviewed-by: Robert Griesemer <gri@golang.org>
Given we promise deterministic encoding, and decoding is also
(trivially) deterministic, it's viable to add another test to
ensure that decoding and encoding an IconVG file gives us the
same bytes back.
Since the Encoder.HighResolutionCoordinates option is not a
part of the image metadata but needed for this test to work,
obtain it from the filename.
Also remove some comparisons of adj that can never be false
because no value of type uint8 is less than 0.
Change-Id: I356ec01c8dd582aaeff14b39bb0272ca93eb1d2a
Reviewed-on: https://go-review.googlesource.com/c/exp/+/279295
Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Nigel Tao <nigeltao@golang.org>
Trust: Nigel Tao <nigeltao@golang.org>
Trust: Dmitri Shuralyov <dmitshur@golang.org>
Add explicit rounding in Encoder.SetEllipticalGradient to disable
fused operations. This allows the TestEncodeElliptical case to pass
on GOARCH=arm64. Otherwise, fused multiply-sub instructions are
used on GOARCH=arm64 (but not GOARCH=amd64), which results in a
slightly different real value being computed for a "Set NREG"
instruction (with a tiny delta of 7.450581e-09), and then
encoded into non-identical bytes:
ac Set NREG[NSEL-4] to a real number
-00 0
+03 00 00 b2 -7.450581e-09
Document the IconVG design decision that the encoder aims to
produce byte-identical output on all supported platforms per
suggestion in golang.org/issue/43219#issuecomment-748531069.
This should make it clear for the future—if another similar
problem is detected—that the encoder implementation should
be fixed (rather than relaxing Encode tests to allow for
non-deterministic encoding). It also allows package users
to be aware that the encoder is platform-agnostic and not
have to take additional measures themselves. (If this proves
to be truly unsustainable to maintain, it is still viable to
remove it given the "SUBJECT TO INCOMPATIBLE CHANGES" clause.)
Rename TestRasterizer to TestDecodeAndRasterize since it tests
both decoding and rasterizing. There isn't another test that
tests only the Decode function.
Fix some broken links to the material-design-icons repository.
Fixesgolang/go#43219.
Updates golang/go#11811.
Change-Id: I5cf15541a4648e408c9c61689041c678c14441bf
Reviewed-on: https://go-review.googlesource.com/c/exp/+/279294
Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Dmitri Shuralyov <dmitshur@golang.org>
Trust: Nigel Tao <nigeltao@golang.org>
Reviewed-by: Nigel Tao <nigeltao@golang.org>
Remove build constraints for Intel architectures on macOS,
they're not needed. This fixes the build on M1 Macs.
Update to a newer version of the gl package with support
for darwin/arm64 that was added in CL 278779.
Fixesgolang/go#43237.
Change-Id: I813d6ec9656463caafcd2daa08986c1bee62433f
Reviewed-on: https://go-review.googlesource.com/c/exp/+/278761
Trust: Dmitri Shuralyov <dmitshur@golang.org>
Trust: Nigel Tao <nigeltao@golang.org>
Reviewed-by: Nigel Tao <nigeltao@golang.org>
The Objective-C BOOL type is defined as a signed char on on Intel-based
Mac computers, but on Apple silicon, it is defined as as a native bool.¹
This makes it hard to write portable Cgo code across darwin/amd64 and
darwin/arm64 ports. So, stop relying on it, and use the bool type from
<stdbool.h> instead.
Update to a newer version of the mtl package with a similar change.
¹ https://developer.apple.com/documentation/apple_silicon/addressing_architectural_differences_in_your_macos_code#3616879Fixesgolang/go#43221.
Change-Id: I63334dc646a8f9b74cd6a969eadf133cdbc84fb7
Reviewed-on: https://go-review.googlesource.com/c/exp/+/279293
Trust: Dmitri Shuralyov <dmitshur@golang.org>
Trust: Nigel Tao <nigeltao@golang.org>
Reviewed-by: Nigel Tao <nigeltao@golang.org>
Update to a newer v3.3/glfw pseudo-version, which uses GLFW 3.3.2.
GLFW 3.3.2 includes a fix for glfw/glfw#1543 (go-gl/glfw#262),
which makes it possible to remove the workaround for it from mtldriver.
However, there is a new regression glfw/glfw#1649 (go-gl/glfw#272).
Fortunately, it's a smaller issue. Add a temporary workaround for it.
Also update comment in two internal packages. The upstream names were
modified in 11308bd612
to match the names used here.
Change-Id: I3199f16890efd539d62d8914b92260f8a614449a
Reviewed-on: https://go-review.googlesource.com/c/exp/+/220639
Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Hajime Hoshi <hajimehoshi@gmail.com>
Under certain circumstances Windows sends `_WM_SYSKEYDOWN` and `_WM_SYSKEYUP` messages instead of `_WM_KEYDOWN` and `_WM_KEYUP` messages.
This handles the `SYSKEY` messages in the same way as the other messages, to be able to forward all key events to the application.
The exact circumstances are when the key is F10 or when the ALT key is currently pressed while another key is pressed. This behavior is documented in the Windows documentation [here](https://docs.microsoft.com/en-us/windows/win32/inputdev/wm-syskeydown).
Fixesgolang/go#36213.
Change-Id: I12ef1b45110a2e02ce319b12c1e6d93a011e5fab
GitHub-Last-Rev: 60a04482b2
GitHub-Pull-Request: golang/exp#8
Reviewed-on: https://go-review.googlesource.com/c/exp/+/212403
Run-TryBot: Alex Brainman <alex.brainman@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
This reverts CL 154461.
[NSOpenGLContext update] must be called from the main thread if the
context has a view. The makeCurrentContext function is not called from
the main thread, so it is not thread safe to make a direct [ctx update];
call in it. Doing so causes gldriver to crash with a SIGILL signal when
compiled with Xcode 11.1 or newer on macOS Catalina.
Fixesgolang/go#35177
Change-Id: I566c9526cddf31ed981312466f8843c2030d6692
Reviewed-on: https://go-review.googlesource.com/c/exp/+/212245
Reviewed-by: Nigel Tao <nigeltao@golang.org>
This is a fixup to CL 208877. The intention there was to select
between receiving a value from the newWindowCh or done channels.
Instead, it was receiving only on the newWindowCh channel,
before proceeding to select between sending to newWindowCh
and receiving from done. That means a shiny program that doesn't
open a window could never exit. This change fixes that.
Change-Id: I1c09ea5f7bec6c9714f20428fdd90d1b756f515d
Reviewed-on: https://go-review.googlesource.com/c/exp/+/209257
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
GLFW v3.2 was old and started generating some warnings on macOS 10.15
Catalina (and warnings get upgraded to errors on builders). Update to
GLFW v3.3 that was recently released to resolve the problem.
There is a small regression affecting the newer version of GLFW that is
being tracked in issues https://github.com/glfw/glfw/issues/1543 and
https://github.com/go-gl/glfw/issues/262. It causes the application to
crash when glfwWaitEvents is called before the first window is opened:
$ go run -tags='example metal' .../shiny/example/basic
2019-11-25 22:19:24.715 basic[9412:69556] *** Assertion failure in -[NSApplication run], /BuildRoot/Library/Caches/com.apple.xbs/Sources/AppKit/AppKit-1894.10.126/AppKit.subproj/NSApplication.m:3313
2019-11-25 22:19:24.715 basic[9412:69556] *** Terminating app due to uncaught exception 'NSInternalInconsistencyException', reason: 'NSApp with wrong _running count'
*** First throw call stack:
(
0 CoreFoundation 0x00007fff30503f53 __exceptionPreprocess + 250
1 libobjc.A.dylib 0x00007fff665c9835 objc_exception_throw + 48
2 CoreFoundation 0x00007fff3051f810 +[NSException raise:format:arguments:] + 88
3 Foundation 0x00007fff32bff5d1 -[NSAssertionHandler handleFailureInMethod:object:file:lineNumber:description:] + 191
4 AppKit 0x00007fff2d657ed3 -[NSApplication run] + 1007
5 basic 0x00000000040d473d _glfwPlatformCreateWindow + 77
6 basic 0x00000000040cd945 glfwCreateWindow + 485
7 basic 0x00000000040da71b _cgo_78603e0816ec_Cfunc_glfwCreateWindow + 43
8 basic 0x0000000004058430 runtime.asmcgocall + 112
)
libc++abi.dylib: terminating with uncaught exception of type NSException
SIGABRT: abort
PC=0x7fff67a7b49a m=0 sigcode=0
signal arrived during cgo execution
[...]
Work around it by waiting for the first window open request before
entering the main loop. That way, glfwWaitEvents is not called
before a window has been created, and the crash does not occur.
This temporary workaround can be removed after the bug is fixed.
Fixesgolang/go#35766
Updates go-gl/glfw#256
Updates glfw/glfw#1543
Updates go-gl/glfw#262
Change-Id: Ie9b15ab6632af39871d94993a3e3097ea798a7e2
Reviewed-on: https://go-review.googlesource.com/c/exp/+/208877
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
The OpenGL API has been deprecated on macOS as of version 10.14.¹
The replacement for OpenGL on macOS is the Metal API.² This change adds
the start of a Metal API-based shiny driver. It can be activated by
specifying the -tags=metal build tag on macOS 10.13+. For example:
go run -tags='example metal' golang.org/x/exp/shiny/example/icongallery
The goal of this CL has been to create an MVP. As a result, the focus is
on simplicity and correctness. Performance optimizations can come later.
The Metal API is currently used only to present the final pixels to
the screen. All rendering is performed on the CPU via the image/draw
algorithms (see https://blog.golang.org/go-imagedraw-package).
Future work is to use mtl.Buffer, mtl.Texture, etc., to do more of
the rendering work on the GPU.
From what I've observed so far, the Metal API is looking to be a great
fit for implementing the screen.Screen interface. But we'll learn more
when it's used to a greater extent of its full performance potential.
GLFW v3.2.1 is used for window creation, receiving input events, etc.
Package dmitri.shuralyov.com/gpu/mtl is used for Metal API access.
Helper packages for Apple's Core Animation and AppKit APIs are copied.
References:
¹ https://developer.apple.com/documentation/macos_release_notes/macos_mojave_10_14_release_notes?language=objc#3035786
² https://developer.apple.com/metal/
Change-Id: I0e02d660b776820ca499bfe7d67e47a9866d530c
Reviewed-on: https://go-review.googlesource.com/c/exp/+/171025
Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Nigel Tao <nigeltao@golang.org>
Handle MappingNotifyEvent and reload the keyboard configuration as
needed. This will keep the x11 driver updated when the user changes the
keyboard layout (for example with setxkbmap).
Change-Id: I466d9c221f8e742b813634be429df710cb46aaac
Reviewed-on: https://go-review.googlesource.com/c/exp/+/192777
Reviewed-by: Nigel Tao <nigeltao@golang.org>
key.ControlRight and kVK_RightCommand were found by looking in
HIToolbox/Events.h as well as experimenting with Karabiner-Elements.
Fixesgolang/go#32131.
Change-Id: I90c76a3983109cdc2d0a645d7955b631d94ee2ee
Reviewed-on: https://go-review.googlesource.com/c/exp/+/188378
Reviewed-by: Nigel Tao <nigeltao@golang.org>
Figure out which modifier is the numlock modifier, use the correct
keysym when the numlock modifier is set and map numpad keysyms to their
runes and key.Codes.
Change-Id: If8bb28cc10564aa0ecaf4a45753993496f288d6e
Reviewed-on: https://go-review.googlesource.com/c/exp/+/175084
Run-TryBot: Alessandro Arzilli <alessandro.arzilli@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Nigel Tao <nigeltao@golang.org>
Turn rune returned by x11key.Lookup to upper case if the capslock bit
is set in the state.
Change-Id: Ie9ad67ce7f80a669cbf34194f563dfb1845efa21
Reviewed-on: https://go-review.googlesource.com/c/exp/+/175083
Reviewed-by: Nigel Tao <nigeltao@golang.org>
Closing and re-opening a window caused an error at RegisterClassW call (class already registered). This fixes the problem by correctly unregistering the class.
Change-Id: Ie6e45354096bc1245776264bec9be0c86f53d79c
GitHub-Last-Rev: 34780c2735
GitHub-Pull-Request: golang/exp#6
Reviewed-on: https://go-review.googlesource.com/c/exp/+/171697
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
This CL iterates upon CL 171033 and resolves two remaining C compiler
warnings when building on macOS 10.14:
# golang.org/x/exp/shiny/driver/gldriver
cocoa.m:63:39: warning: 'NSOpenGLCPSwapInterval' is deprecated: first deprecated in macOS 10.14 [-Wdeprecated-declarations]
/Applications/Xcode.app/.../NSOpenGL.h:281:39: note: 'NSOpenGLCPSwapInterval' has been explicitly marked deprecated here
cocoa.m:72:1: warning: method possibly missing a [super prepareOpenGL] call [-Wobjc-missing-super-calls]
NSOpenGLContextParameterSwapInterval is the less-deprecated version of
NSOpenGLCPSwapInterval and respects the GL_SILENCE_DEPRECATION define.
However, we can't use it because it's available only in macOS 10.12+,
but Go currently supports older macOS versions (e.g., Go 1.12 requires
macOS 10.10+). Use a targeted #pragma clang diagnostic ignored instead.
Add a [super prepareOpenGL] call to ScreenGLView.prepareOpenGL method.
I can't quite tell if it was omitted intentionally, but based on its
documentation¹, it seems reasonable to have it. I didn't notice problems
in local testing. If it turns out it shouldn't be there, then it can be
removed in a way that doesn't generate a compiler warning.
¹ https://developer.apple.com/documentation/appkit/nsopenglview/1414940-prepareopengl
Updates golang/go#11811
Change-Id: I10b6522a7af64eadeb6586fad44ef4c1ece40ab2
Reviewed-on: https://go-review.googlesource.com/c/exp/+/171034
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
The OpenGL API has been deprecated on macOS as of version 10.14.¹
Building gldriver on macOS 10.14 produces warnings such as:
# golang.org/x/exp/shiny/driver/gldriver
cgo-gcc-prolog:117:2: warning: 'glBindVertexArray' is deprecated: first deprecated in macOS 10.14 - OpenGL API deprecated. (Define GL_SILENCE_DEPRECATION to silence these warnings) [-Wdeprecated-declarations]
/Applications/Xcode.app/.../gl3.h:2360:21: note: 'glBindVertexArray' has been explicitly marked deprecated here
cocoa.m:35:2: warning: 'NSOpenGLContext' is deprecated: first deprecated in macOS 10.14 - Please use Metal or MetalKit. [-Wdeprecated-declarations]
/Applications/Xcode.app/.../NSOpenGL.h:202:12: note: 'NSOpenGLContext' has been explicitly marked deprecated here
...
The package is named gldriver, so it would be too drastic of a change
for it to stop using OpenGL. Also, OpenGL is not deprecated on all
other platforms that package gldriver supports.
Despite being deprecated, OpenGL is not removed from macOS 10.14 at this
time. It's not helpful for the warnings to be shown to users who are
building and using the package on macOS, so, simply acknowledge the
deprecation notice by defining GL_SILENCE_DEPRECATION and silence the
warnings.
It should also help with x/exp builds passing on https://build.golang.org,
because warnings are promoted to errors in trybots (to help catch issues
such as this one).
References:
¹ https://developer.apple.com/documentation/macos_release_notes/macos_mojave_10_14_release_notes?language=objc#3035786
Updates golang/go#11811
Change-Id: Ie86d03a44c3cdb7aca3ff255bbf7a71926d14025
Reviewed-on: https://go-review.googlesource.com/c/exp/+/171033
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
This seems necessary (at least on Mojave). Otherwise, the window seems to have the wrong viewport until it is moved or resized.
Change-Id: I0efd372e875e37056974a9d1ae99ba47896f69d5
GitHub-Last-Rev: bc6b239087
GitHub-Pull-Request: golang/exp#5
Reviewed-on: https://go-review.googlesource.com/c/154461
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Nigel Tao <nigeltao@golang.org>
CL 133155 adds the internalFormat parameter to TexImage2D. Fix
the two usages of TexImage2D in this repository.
Change-Id: Id529c755f47202d10f8aeec0f85f8f4e0d6fcfd1
Reviewed-on: https://go-review.googlesource.com/133175
Reviewed-by: Nigel Tao <nigeltao@golang.org>
Calling DestroyWindow in Release is not allowed when
running on a different thread than the message pump.
This sends a WM_CLOSE message instead, that is handled by
the message pump itself.
Fixesgolang/go#25671
Change-Id: Ie8610a8385faa2746dc7eabac11edc1106e8bb6e
Reviewed-on: https://go-review.googlesource.com/115998
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
After receiving a close request from the window manager,
DestroyWindow must be called to actually close the window.
This is done by DefWindowProc.
Fixesgolang/go#25587
Change-Id: I05c95046ce4572fec0cba67eba2d313f318e36ba
Reviewed-on: https://go-review.googlesource.com/115515
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
The garbage collector considers slice elements past len to be
reachable, since the slice may be resliced to those elements at any
time. That means that elements past len(q.front) will remain reachable
until the next time len(q.front) again reaches its largest value.
Since we don't actually know when that will occur, nil out consumed
entries to allow their events to be collected as soon as possible.
Change-Id: I7bc914eebfd7dec42933b9fa5ad256d4db3701ab
Reviewed-on: https://go-review.googlesource.com/94135
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
We mostly re-use existing X11/Linux or X11/Dragonfly code.
Notes:
- in OpenBSD, all X11 headers are in /usr/X11R6, thus we need to add this to the linker and include paths
- in OpenBSD, we seem to need to open MIT-SHM segments with 0666 rights - this could be fixed by passing the SHM segment by file descriptor instead, via X_ShmAttachFd & co.
Change-Id: I2c2d50b5f8d9f1ee2c9c64d131b556d5e337be6f
Reviewed-on: https://go-review.googlesource.com/79917
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
This CL makes screen.NewWindowOptions.Width and
screen.NewWindowOptions.Height parameters of screen.NewWindow
set window's client area of the specified window, instead of
setting dimensions of the bounding rectangle.
Fixesgolang/go#19704.
Change-Id: Ic8a819e8127b89cc2734ed26dff6be06d2446ab1
Reviewed-on: https://go-review.googlesource.com/39111
Reviewed-by: Nigel Tao <nigeltao@golang.org>
Set the windowImpl.sz cached value on the receiver side of the channel
communication, not spawned by a goroutine 'soon' after the send.
This CL only affects x11. The same change applies in principle to cocoa
and win32, but I have not (manually) tested it there yet.
Change-Id: Ibe4bad965fe0c059378daef2f535dcae362447a9
Reviewed-on: https://go-review.googlesource.com/37918
Reviewed-by: David Crawshaw <crawshaw@golang.org>
Its bytes are passed to C libraries, so we sanitize as a precaution.
Change-Id: I6ecdd5388be40c4067815ba0484112bea6c55270
Reviewed-on: https://go-review.googlesource.com/37414
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
Titles are UTF-8 compatible on all platforms; drivers
default to an empty string.
Change-Id: I4cf1a16ceb4e9641b2e1fc78dcff0501aac7dedb
Reviewed-on: https://go-review.googlesource.com/37200
Reviewed-by: Nigel Tao <nigeltao@golang.org>
DragonflyBSD supports all the functionality needed, but was excluded
by build tags.
Change-Id: If7fb237ad0b652686f8e32d11fc1f721b455bb91
Reviewed-on: https://go-review.googlesource.com/36475
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Windows mouse wheel events report the cursor position in
absolute screen coordinates, while other mouse event's positions
are relative to the window.
This adds ScreenToClient to syscall_windows.go and converts the
event's position for mouse wheel events.
Fixesgolang/go#18695
Change-Id: Ic086033e435cf4699c7ff0aad90e1a1ce233bb02
Reviewed-on: https://go-review.googlesource.com/35412
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
A *windowImpl's glctx and worker fields should really be set on
construction (and never modified afterwards), as fields in the
&windowImpl{ etc } literal during screenImpl.NewWindow. However, the
initialization values are platform specific, so they are initialized in
a separate function call.
Until now, that function call was showWindow, as it is called
conveniently soon after newWindow returns. showWindow's primary purpose
is mostly unrelated: to show the freshly created window on the screen.
Soon isn't soon enough, though. The (implemented in C) message pump
happens in another thread, which can trigger callbacks like onConfigure,
which (racily) reads the w.glctx field with lines like:
w.lifecycler.SendEvent(w, w.glctx)
This commit fixes the race, originally reported at
https://github.com/golang/exp/pull/3
Change-Id: I69d50b037ec4c4f021ca60f570f86723c17d7bb7
Reviewed-on: https://go-review.googlesource.com/34873
Reviewed-by: David Crawshaw <crawshaw@golang.org>
Bryan C. Mills
Nigel Tao
Russ Cox
Dmitri Shuralyov
jopbrown
Green Lightning
aarzilli
smasher164
Mirko Hansen
Elias Naur
Ethan Burns
Elias Naur
unknown
Giovanni Bajo
tomheng
Sergiusz Bazanski
Alex Brainman
Fabian Zaremba
Dave MacFarlane