All accesses to the view map now happens on the main thread, so
there is no need for a sync.Map anymore.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
Recent changes to the macOS threading exposed a problem where a
window's display link may fail to start after being started and stopped
in rapid succession.
Introduce a displayLink type that waits a while after the last stop
request before stopping its display link. That seems to be the way
other projects are using display links.
As a bonus, the new implementation avoids the potentially expensive
overhead of frequent starting and stopping the underlying OS thread.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
We're about to move the display link to common Go code. To do that,
we need the redraw logic in Go as well.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
The macOS redraw callback is not invoked on the main thread, so its
access to window fields must be synchronized.
An alternative would be to schedule the asynchronous redraws on the main
thread, but I believe frame callbacks are performance-sensitive enough
to warrant the extra locking complexity.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
Only the synchronous draws from the main thread may involve changing
width, height and scale. Introduce cached window.width and window.height
fields and limits updates to main-thread draws.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
Key had an unfortunate association with keyboard input.
This is an API change. The following rewrites were run to fixup
Gio code:
$ gofmt -r 'pointer.InputOp{Key:a} -> pointer.InputOp{Tag:a}' -w .
$ gofmt -r 'pointer.InputOp{Key:a, Grab:b} -> pointer.InputOp{Tag:a, Grab:b}' -w .
$ gofmt -r 'key.InputOp{Key:a} -> key.InputOp{Tag:a}' -w .
$ gofmt -r 'key.InputOp{Key:a, Focus:b} -> key.InputOp{Tag:a, Focus:b}' -w .
$ gofmt -r 'event.Key -> event.Tag' -w .
Signed-off-by: Elias Naur <mail@eliasnaur.com>
The app.ReadClipboard and app.WriteClipboard can be used to interact
with the system clipboard. The clipboard may be asynchronous, so
system.ClipboardEvent is introduced to deliver the result of a read.
Updates gio#31
Signed-off-by: Elias Naur <mail@eliasnaur.com>
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>
Elias Naur