I have a class that schedules patterns, events and functions on the system clock (bind-ing the functions to adjust for latency).
I’m displaying .png images in a Qt window
using this method to display the images
var w = Window(bounds:Rect(1500*monitor,200,1400,800),border:false)
A bit ironic, because the first sentence explains why the second sentence is necessary
Graphics operations are not guaranteed to be fast, so they have to be on a lower priority thread.
There was a discussion once whether graphics methods might automatically defer, but it’s easy to imagine cases where you need A, B and C to happen in that order. An obvious case would be Button.new.states_([["OK"]]) – the button must exist before you can set its display strings. If new and states_ are separately deferred, we would have to be very sure that it will never try to handle states_ first – i.e. a lot of careful design and testing. (And, tbh, there hasn’t been that much demand for it.)
Latency… the graphics updates don’t know how much latency is applied to server messaging. If you’re using patterns and events, server .latency is a good guess but you might be using a custom event prototype that handles latency differently. In a Routine, latency is totally up to you. So it’s another one that seems like it should be easy but when you try to pin down what the latency is in every possible situation (and if it’s automatic, then it does have to handle every foreseeable case), then it’s not so straightforward.
I agree that the syntax looks clunky but improving that is a bigger job than it would seem. (But, SC is a do-ocracy so anyone who feels strongly about it can start by building some tests to see if auto-scheduling on AppClock is order-safe or not.)