The _NET_WM_STATE protocol description[0] states that to change the
window mode for an X11,
"To change the state of a mapped window, a Client MUST send a
_NET_WM_STATE client message to the root window."
and that the window manager in turn
"The Window Manager MUST keep this property updated to reflect the
current state of the window."
However, our X11 implementation did both: send the message _and_ set or
deleted the property.
This change makes it so only the message is sent. It also replaces
toggling the property by setting or clearing, to ensure our mode and the
window manager's mode never gets out of sync.
Maybe fixes gio#265
[0] https://specifications.freedesktop.org/wm-spec/wm-spec-latest.html#idm46515148826720
Signed-off-by: Elias Naur <mail@eliasnaur.com>
A Window configuration with its current option values can now be fetched during a FrameEvent.
The WindowMode and Orientation options have moved to methods on their corresponding types.
Fixes#260
Signed-off-by: Pierre Curto <pierre.curto@gmail.com>
Now that Window.driverDefer can be run in any context, the special case
of setting the animation flag can use that mechanism instead of a
special purpose channel.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
Driver methods are invoked during event processing, but some of them may
generate events that would in turn deadlock because event processing is
not re-entrant. However, a previous change moved all such calls outside
event processing and so chained events can no longer deadlock.
This change deletes the workarounds.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
Window.driverRun is designed to run functions on the driver event
goroutine, to avoid race conditions with internal driver state and,
more importantly, to run on the designated main or UI thread for
platforms that require that.
However, driverRun runs functions during the processing of a driver
event, so if a function in turn triggers another driver event,
deadlock occurs.
This change introduces Window.driverDefer for functions that don't need
to block event processing. Functions passed to driverDefer may
themselves trigger new events.
A few callers of driverRun remain; they need the result of their
functions but are guaranteed not to trigger new events.
Fixes gio#263
Signed-off-by: Elias Naur <mail@eliasnaur.com>
Since onFrameCallback runs on the app UI thread, using plain
invalidate() can be used instead of postInvalidate(). The latter just
schedules a call to invalidate() on the UI thread.
Also, since onFrameCallback is directly called by JNI, there is no need
to set up a new JNI environment to call back into Java.
Signed-off-by: Felix Lange <fjl@twurst.com>
Some window configurations lead to WM_SIZE messages when changed, which
leads to deadlock because our window proc is not re-entrant. Avoid the
issues by ignoring redundant messages.
Fixes gio#262
Signed-off-by: Elias Naur <mail@eliasnaur.com>
Before this change, the renderLoop type implemented a rendering
goroutine for rendering off the event thread. However, it's not worth
the complexity, so remove it and render on the event thread.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
The Android emulator creates a broken EGL surface if it is not created
on the same thread as the context is made current.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
The Android system can in some cases replace the GioView of our Android
Activity before destroying the previous one. This change makes sure the
previous view is ignored, in particular its destroy event.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
The app and app/internal/wm packages are tightly coupled, requiring
quite a bit of forwarding types, values and constants from the internal
package to export it. Further, no other package imports package wm.
This change merges the two packages.
While here, drop the pre-Go 1.14 SIGPIPE workaround.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
window.Wakeup assumes the window.w field is never reset to nil. Avoid
doing that in gio_onClose.
While here, ensure a valid window handle in window.Close by calling
the checked window.runOnMain method, not the bare runOnMain function.
Fixes gio#258
Signed-off-by: Elias Naur <mail@eliasnaur.com>
There's no meaningful reason to have them separate. The intention was to
enable rendering concurrent with other processing, but that's gaining
framerate at the expense of input latency and complicating ImageOp
semantics.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
We shouldn't need more than 2 drawables, but changing the count from the
default of 3 introduces framerate lags in fullscreen mode.
This changes leaves the drawable count alone. No good deed goes
unpunished.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
The OpenGL (ES) implementations on Apple platforms are deprecated and
don't support GPU compute programs. This change adds support for the
replacement, the Metal GPU API.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
Instead of handing the internal/wm driver a method to run code on the
(blocked) main thread, just run the necessary driver methods on the main
thread.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
The only reason for separate files is Objective-C callbacks into Go,
or when the Go side is common, yet the Objective-C side differs from
macOS to iOS.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
Both the OpenGL and the Direct3D API are stateful and gpu.GPU renders to
the render target current when Frame is called.
Modern GPU API such as Metal don't have a concept of a current render
target, and the target even changes each frame.
Add RenderTarget and add an explicit target argument to GPU.Frame as
well as the underlying driver.Device.BeginFrame.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
Otherwise, making a context current on another thread may result in
an EGL_BAD_ACCESS error.
Fixes gio#248
Signed-off-by: Elias Naur <mail@eliasnaur.com>
Releasing the renderer is fine, but releasing the underlying context
introduces flicker when restoring a Gio window on macOS.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
The platform GPU context must be Refreshed on the window event thread,
but our rendering loop must not, because it may also want access to the
window event thread.
Fixes gio#236
Signed-off-by: Elias Naur <mail@eliasnaur.com>
The app.Window owner may run SetAnimating just before window close,
which in turn rely on an active display link. This change makes sure
the link is stopped after window close where no more driver calls
can occur.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
The macOS app menu would respond to clicks, only to shotcuts (Cmd-Q,
Cmd-H). Moving setActivationPolicy to applicationDidFinishLaunching
seems to fix that, although I can't explain why.
Move a SetDriver call after initialization while here.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
The NSViewGlobalFrameDidChangeNotification notification is documented to
be fired every time [NSOpenGLContext update] needs to be called.
However, the notification fails to fire on my setup when a window is
moved to a display with a different pixel scale, which leads to
incorrectly sized output.
This change gets rid of the notification and updates the context before
every frame.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
Now, it's possible to use `app.Fullscreen` on Android devices. It uses
the "Fullscreen Sticky Immersive" mode.
Signed-off-by: Inkeliz <inkeliz@inkeliz.com>
Previously, the on-screen keyboard always displays the text keyboard,
(QWERTY or equivalent).
For optimal user experience, it's possible to specify the keyboard type
using `InputHint`. The on-screen keyboard will provide shortcuts or
restrict what the user can input.
Due to some limitations (gio#116), only numeric and text keyboards are
supported on Android.
Signed-off-by: Inkeliz <inkeliz@inkeliz.com>
Instead of a single racy window.driver field, maintain a driver
reference for each goroutine that needs it: the window.run event loop
and the callbacks structure.
Fixes gio#230
Signed-off-by: Elias Naur <mail@eliasnaur.com>
This changes moves the macOS specific setup for desktop OpenGL to the
portable opengl package. The opengl package already takes care of the
desktop OpenGL setup for sRGB framebuffers, and by moving the code we
avoid calling the wrong OpenGL functions in case both OpenGL.framework
and ANGLE libGLESv2.dylib is linked into the program.
Remove the interface casting expressions for gl.Functions; it wasn't
worth the trouble to keep updated.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
Elias Naur