On compositors that support compositor key repeat events, use those, for
complete robustness. Sadly no actual compositor implements these yet.
Otherwise use a timer fd/pipe to queue the repeat events and only
dispatch them after events from the compositor are handled. This means
release events from the compositor will prevent spurious repeat events.
One can, in the worst case lose some repeat events if there is a very
large interval between the start of the timer and the next poll, but
that is unavoidable and is why repeat events should come from the compositor
in the first place.
Fixes#9224
Far more robust. Sadly no actual compositors yet support this. Fifteen
years it takes Wayland developers to correct their most basic mistakes.
See #9224
The locks were not being initialized, and since I was there did some
general cleanup as well, moved the locks array into displayLinks rather
than having another global namespaced variable.
Apparently on some systems Tahoe sends a resize event on wake from
sleep/lid open for obscure reasons and then proceeds to crash if one
redraws during that event. Sigh.
This is nicer now every OS Windows doesnt cause a notification. Also
fixes#9034 which was caused by us setting an explicit appearance on the
window when the titlebar is set to a specific color thereby preventing
the views in the window from getting appearance change notifications.
There were two issues.
1) Setting window background color to a non-zero opacity causes
darkening (essentially there were two layers of blending)
2) The titlebar background view could end up in the wrong position
because it was a child of the content view rather than its super view
Fix both issues setting the window background to clear color and
moving the background view into the super view while making sure it is
positioned correctly using explicit constraints. Phew.
This reverts commit d837a64e36.
Commit 24b31d96e9 fixes the original
problem of "ghost windows" that d837a64 was trying to solve. (I have no
idea how or why it does.)
One side-effect of the workaround from d837a64 is that it causes closed
windows to be moved to the (0,0) before being destroyed. This means that
when creating new windows, they are placed on the left-most display,
instead of the display in which the previously closed window was on as
you would expect. Reverting this kludge fixes this bug.
Dont redraw an OSWindow during a resize event if the resize event is
accompanied by a screen change as it causes a crash in macOS OpenGL
driver. Fixes#8983
