Change gioui.org/commit/0e70fbc1262920a69c60409285795b6bb8701b09
added a note that app.Window.Queue must only be used during the
processing of a FrameEvent. The change was added because a Gio
user took the existence of app.Window.Queue to mean it was always
available.
This change reduces the scope of window Queues by moving it from Window
to FrameEvent, and minimizes the risk of misuse by not offering
Window.Queue at all.
Note that the gioui.org/commit/a937a7653439333b8c6fc30c7a6039b717339766
change moved Window's Frame method (named Update) to FrameEvent for the
same reason.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
By default, the standard library log package outputs to stderr.
However, stderr is redirected through a pipe to the Android logger,
so recent writes may be not have been sent when os.Exit is called.
The log.Fatal family of functions does just that: write to the log
and call os.Exit.
To ensure all messages are sent, register a synchronized logger at
startup.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
According to
https://developer.apple.com/library/archive/documentation/Cocoa/Conceptual/Multithreading/CreatingThreads/CreatingThreads.html#//apple_ref/doc/uid/20000738-125024
Cocoa is by default not multithread-safe for programs that use the posix
api for creating threads:
"
For multithreaded applications, Cocoa frameworks use locks and other
forms of internal synchronization to ensure they behave correctly. To
prevent these locks from degrading performance in the single-threaded
case, however, Cocoa does not create them until the application spawns
its first new thread using the NSThread class. If you spawn threads
using only POSIX thread routines, Cocoa does not receive the
notifications it needs to know that your application is now
multithreaded. When that happens, operations involving the Cocoa
frameworks may destabilize or crash your application.
"
That includes Go programs.
The fix, as discovered by Steeve Morin, is to create and launch
an empty NSThread.
Add a package that does that, and use it everywhere Cocoa is used.
Sigh.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
The macOS backend doesn't re-create contexts, holding on to the first
created instead. Make sure the GPU leaves the default framebuffer bound,
in case the context is re-used.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
While we're here,
- replace the registerFragment trampoline with a general variadic
CallVoidMethod trampoline.
- Use UTF-16 for passing strings to Java. Java's modified UTF-8 encoding differ
from Go's in corner cases.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
I've resisted relying on pkg-config in the hope that hard-coded include and
library paths would suffice. However, apart from having to work around some
distro-specific differences, building with hardcoded include paths fails when
building on a buildroot:
x86_64-buildroot-linux-gnu-gcc: ERROR: unsafe header/library path used in cross-compilation: '-I/usr/include/wayland'
(see #91)
Andri mentions a workaround (prefixing paths with "="), but that doesn't seem
to work on the BSDs.
Let's see how pkg-config fares. It's an extra dependency, but it promises to keep
us isolated from the varying paths on Linux distrobutions.
Updates #91
Signed-off-by: Elias Naur <mail@eliasnaur.com>
EGL is window system agnostic, but its egl.h header includex X11
headers by default. Use the MESA_EGL_NO_X11_HEADERS define to avoid
it, fixing the "nox11" build for systems without X11 headers installed.
Fixes#91
Signed-off-by: Elias Naur <mail@eliasnaur.com>
Specifying the clear color and depth at the time of clearing is
less error prone and a better for modern GPU APIs. As a bonus, we
can get rid of the BufferAttachment type.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
Direct3D 11 supports Direct3D 9.1 level hardware, but only if the shaders are
compiled for target 4_0_level_9_1.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
D3DCompile successfully compiles shaders fxc.exe doesn't. As a bonus
the DirectX SDK is no longer required (it includes fxc.exe).
Signed-off-by: Elias Naur <mail@eliasnaur.com>
In particular, the simplifying "-s" flag to gofmt ensures that the automatic
test for unformatted Go source files won't complain.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
Some GPU APIs such as Direct3D can return an error after drawing
a frame indicating a transient device error. Recreate device and
retry if it happens.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
Add a series of low level gpu.Backend tests to assure the correct behaviour of
Backends. The immediate use is debugging of the Direct3D port, in the future
for developing new backends.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
The new Framebuffer.ReadPixels method is enough to implement
Window.Screenshot. Use that instead of the OpenGL-specific
implementation.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
The error message is not appropriate where there are multiple backends,
and there's a much better chance Gio will run with the direct3d backend
where no external DLLs are required.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
The srgb package was recently created to contain just the sRGB
emulation, but the names weren't shortened accordingly.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
To prepare package headless for multiple backends, refactor the common headless
driver to no longer assume an OpenGL context. Instead, introduce a headless
backend type and the OpenGL implementation, glBackend.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
This is a refactoring change to prepare for another gpu.Backend
implementations.
Notably, app/loop.go no longer imports gpu/gl.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
Elias Naur