Il ridimensionamento / trascinamento della finestra viene attivato dagli eventi del mouse, che vengono infine avviati dall'hardware. Gli eventi vengono messi in coda e il thread dell'interfaccia utente è dedicato al monitoraggio della coda e alla risposta a qualsiasi cosa letta da quella coda. Quindi, anche in uno scenario single core questo non dovrebbe richiedere troppo tempo. Potrebbe essere in ritardo di un paio di millisecondi se il sistema è occupato ma non è probabile che lo noterai.
Le animazioni sono controllate da timer. Trascorrerà un timer dopo un periodo preimpostato, momento in cui potrà essere srotolata una serie di scenari. Il timer sarà di nuovo basato sull'hardware, sebbene possa esserci un po 'di conteggio anche a livello di software (OS). Il punto è che i timer sono poco costosi per quanto riguarda il carico di lavoro della CPU, difficilmente rivendicano l'elaborazione della CPU. Quando il timer scade, l'immagine successiva nell'animazione verrà disegnata in modo molto simile alla finestra che viene trascinata. Può essere un gestore di eventi nell'interfaccia utente che determina quale immagine deve essere disegnata dopo, potrebbe anche essere un thread segnalato (risvegliato), quel thread che seleziona l'immagine successiva e che innesca un evento Repaint, senza il thread dell'interfaccia utente sapendo cosa sta disegnando. Esistono diversi modi per implementarlo.
What about when an animation plays and the user does something on the
screen while the animation is still running?
L'unica volta che il sistema sta effettivamente lavorando sull'animazione è quando l'immagine cambia. Sarebbe "quasi mai".