app,app/internal/wm: introduce app.Window.Run and use it internally

app.Window implements a method for safely running functions against the
underlying native window through the driverFuncs channel. However, the
functions still run in a different goroutine than the one driving the
native event loop, which forces the implementations in package wm to do
complicated synchronization.

A previous change added a mechanism to run functions in the native event
loop thread. The macOS port needed this functionality, but with some
care it can be generalized. That's what this change does through the
new Run method.

The advantage is that the thread switch dance is now confined to
app.Window, with the help of a generic wm.Driver.Wakeup method. All
other Driver methods can then assume they run on their event loop
threads.

Run is exported because it is also needed for programs that use
Windows configured with CustomRenderer to control their own rendering.

Signed-off-by: Elias Naur <mail@eliasnaur.com>
This commit is contained in:
Elias Naur
2021-05-18 12:34:58 +01:00
parent c914935169
commit 8611894b4b
14 changed files with 283 additions and 380 deletions
+7 -1
View File
@@ -32,6 +32,8 @@ type Options struct {
CustomRenderer bool
}
type WakeupEvent struct{}
type WindowMode uint8
const (
@@ -59,7 +61,7 @@ type Callbacks interface {
// Func runs a function during an Event. This is required for platforms
// that require coordination between the rendering goroutine and the system
// main thread.
Func(f func())
Run(f func())
}
type Context interface {
@@ -99,6 +101,8 @@ type Driver interface {
// Close the window.
Close()
// Wakeup wakes up the event loop and sends a WakeupEvent.
Wakeup()
}
type windowRendezvous struct {
@@ -137,3 +141,5 @@ func newWindowRendezvous() *windowRendezvous {
}()
return wr
}
func (_ WakeupEvent) ImplementsEvent() {}