Before this change, we had a viewDo that serialized a function on a view
on a single goroutine. For better or worse, most callbacks in Cocoa
happen on the main thread, so we might as well use that.
The only exception is the frame callback from the CADisplayLink.
We could force that through the main thread as well, but for
efficiency settle with making the view-to-window map synchronized.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
Asynchronous drawing happens only in onFrameCallback, where we have to
check for disappearing views. onDraw however, is synchronous and should
always have a valid view.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
Before, the wakeup pipe both woke the event loop and implied a redraw.
We're going to use the notication for more, so deduce the need for redraw
from window state instead.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
The implementation was too optimistic: some platforms require a
window context for accessing the clipboard.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
Before, notifying the event loop implied a redraw. Derive the need
for redrawing expliticly and use the notification pipe for wakeups
only.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
Multiple Wayland windows are now separate, except for the global callback
reference map. Use a sync.Map to support multiple concurrent windows.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
The callbackMap is used to look up Go references in event callbacks. Instead
of registering one entry for each possible callback type, use a single
handle for each Go reference.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
Set the fallback environment variables XDG_CONFIG_HOME and HOME to
make os.UserConfigDir and os.UserHomeDir report useful paths.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
os.UserCacheDir can't work on Android because it doesn't have
access to the Java app context. Gio programs do have access, so set
up UserCacheDir's fallback, the XDG_CACHE_HOME environment variable.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
This way, a Gio app's logs can be filtered uniquely, which wasn't
possible before since the tag "gio" would be the same between gio apps.
Since the app ID is supplied at build time, inject it via a variable
with the linker's help. The variable is only used on Android for now,
but that's OK. It might be useful for other platforms or other internal
packages in the future.
Fixes#84.
Signed-off-by: Daniel Martí <mvdan@mvdan.cc>
Android apps may want to run Go code independent of the Gio Android Activity.
Expose a Gio.init Java method public for early loading and initialization of
the Go library.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
There can only be one JNI_OnLoad callback per JNI library, and the
Gio program may need it for its own purposes.
Gio only used JNI_OnLoad for explicitly registering native methods. Switch
to implicit name based registration and get rid of JNI_OnLoad.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
We're about to remove the global JNI_OnLoad constructor, and the
JavaVM singleton is just as easily fetched from a Java JNI callback.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
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>
Elias Naur