Порядок отметок времени в requestAnimationFrame и событиях мыши - PullRequest
Новая
       35

Порядок отметок времени в requestAnimationFrame и событиях мыши

0 голосов
/ 23 апреля 2020

Я столкнулся с проблемой, когда временные метки, полученные в requestAnimationFrame обратных вызовах и событиях мыши, по-видимому, не в порядке, я имею в виду, что они будут увеличиваться (поскольку я надеюсь, что время идет только в одном направлении :)), но, похоже, это не так. Это может быть проиллюстрировано следующим примером кода: 

<html><body>

<script type="text/javascript">
    let lastTimesamp = -1;

    function log(name, timestamp) {
        console.log(name, timestamp);
        console.assert(lastTimesamp < timestamp, "Invalid time", lastTimesamp, timestamp);      
        lastTimesamp = timestamp;
    }   

    function update(timestamp) {
        log("update", timestamp);

        requestAnimationFrame(update);
    }

    requestAnimationFrame(update);

    function mouseDown(event) {
        log("mouseDown", event.timeStamp);
    }

    document.body.addEventListener("mousedown", mouseDown, false);  
</script>

</body></html>

Если вы начнете щелкать мышью, вы в конечном итоге увидите такой результат:

console log output

, что означает, что событие нажатия мыши произошло перед последним update вызовом.

В моем производственном приложении возникает противоположная ситуация: вызов update выполняется с отметкой времени, которая предшествует последний вызов обратного вызова с помощью мыши.

Может ли кто-нибудь мне это объяснить? Из документации видно, что они необязательно измеряются одинаково, но не приведет ли это к смысл рассчитывать их одновременно?

1 Ответ

2 голосов
/ 24 апреля 2020

Что здесь происходит, так это то, что очередь AnimationFrameCallbacks имеет более высокий приоритет , чем события пользовательского интерфейса.

Таким образом, может случиться так, что ваше событие пользовательского интерфейса сработает в том же кадре, что и кадр рисования, поэтому в этот момент будет установлено значение timeStamp или даже ОС, когда оно получило его в первое место . Но UA предпочтет отдать приоритет AnimationFrameCallbacks вместо обратных вызовов событий пользовательского интерфейса, поэтому обратный вызов события пользовательского интерфейса будет отложен до следующей итерации-l oop.

Поскольку обратный вызов rAF получает собственную временную метку внутри итерации event-l oop, которая будет вызывать ее , эта временная метка будет выше, чем у события пользовательского интерфейса, даже если ее обратный вызов срабатывает раньше.

Также обратите внимание, что Chrome имеет requestAnimationFrame полностью неработающий метод *1017*, поэтому он может не помочь при отладке.

...