Si solo fuera por cores caeria todo
NOOOOOOO. Ahí es donde te estás equivocando. Seguramente no habrás programado multi-hilo y por eso es difícil de ver, de hecho confunde bastante al principio. Si fuera de cores NO caería todo, precisamente cae sólo lo que afecta a los cores que se han retrasado, y es exactamente lo que pasa.
Estás confundiendo render multi-hilo (repartir las API-call entre los cores) con procesamiento multi-hilo.
Si de verdad piensas eso de que caería todo entonces veo difícil poder explicarlo.
Cuando cae la tasa sí, es de GPU, cuando algunos elementos dan saltos, es la CPU, más en concreto los hilos que no les ha dado tiempo a terminar. Si quieres un render a la antigua, resulta que tendríamos bajadas por GPU (las que se ven en el video), pero es que cada vez que un elemento se retrasa, si mantienes el frame hasta que todos estén actualizados también se tendría una bajada de frames. Por ponerlo fácil (creo), si la mitad de los elementos se retrasaran y mantienes el frame, te bajaría a 30 fps por motivos de CPU, si no lo mantienes (que es lo que hacen) te va a todo lo que puede la GPU.
Y que en XO también pasa, pero si es de forma muy leve como es el caso, es lo mismo que cuando en un juego pegas un petardazo y en ese momento te baja ligeramente la tasa de fps por el alpha. Son 60 fps casi constantes con alguna leve bajada, y a mí me molesta menos desde luego que sea de algún elemento que de toda la pantalla.
De hecho algún día aprenderán que las tareas de red deben ir en un hilo asíncrono aparte, así se acabarían los "es por la red" cuando nos tenemos que tragar unos trompicones de cuidado en algunos juegos. Mejor que algunos elementos den algún salto a que se nos atranque toda la pantalla esperando los datos de algún jugador.