The Apple threading documentation [^1] says the following:

> The second argument to pthread_setschedparam is the desired policy,
  which can currently be one of SCHED_FIFO (first in, first out),
  SCHED_RR (round-robin), or SCHED_OTHER. The SCHED_OTHER policy is
  generally used for extra policies that are specific to a given
  operating system, and should thus be avoided when writing portable
  code.

This appears to differ from the policy semantics on Linux and BSD, where
FIFO and RR are both explicitly real-time policies.

Therefore, on Linux/BSD we only enable the RR policy if the requested
priority is 8 or higher. Meanwhile, on macOS, we map all thread
priorities (0 - 10) onto the RR policy with an appropriate priority.

[^1]: https://developer.apple.com/library/archive/documentation/Darwin/Conceptual/KernelProgramming/scheduler/scheduler.html

The Apple threading documentation [^1] says the following:

> The second argument to pthread_setschedparam is the desired policy,
  which can currently be one of SCHED_FIFO (first in, first out),
  SCHED_RR (round-robin), or SCHED_OTHER. The SCHED_OTHER policy is
  generally used for extra policies that are specific to a given
  operating system, and should thus be avoided when writing portable
  code.

This appears to differ from the policy semantics on Linux and BSD, where
FIFO and RR are both explicitly real-time policies.

Therefore, on Linux/BSD we only enable the RR policy if the requested
priority is 8 or higher. Meanwhile, on macOS, we map all thread
priorities (0 - 10) onto the RR policy with an appropriate priority.

[^1]: https://developer.apple.com/library/archive/documentation/Darwin/Conceptual/KernelProgramming/scheduler/scheduler.html

Previously, we were using the window's top-left position to determine
the scale to use for the OpenGLContext. However, on macOS the
backingScaleFactor of the window is not strictly related to the top-left
corner of the window, so the OpenGL view's scale could end up differing
from the backing scale factor when slowly moving a window between
displays with different backing scale factors.

On macOS, we now use the backing scale factor of the window's screen (as
maintained by AppKit), rather than trying to work out the correct
display and scale ourselves.