DEVIEW 2015 - 브라우저는 VSync를 어떻게 활용하고 있을까

더블 버퍼링과 버퍼 스왑의 원리를 설명한다. 그래픽 드라이버가 버퍼에 그린 새 이미지는 곧바로 모니터에 반영되지 않으며, 모니터 화면은 프론트 버퍼의 이미지로만 갱신된다. 버퍼를 프론트·백 둘로 두면 모니터가 항상 완성된 이미지를 가져갈 수 있어 미완성 이미지가 보이는 일을 막는다. 애플리케이션이 백 버퍼에 이미지를 완성하면 프론트 버퍼를 가리키는 주소를 백 버퍼로 바꾸는 단순한 포인터 교체인 버퍼 스왑이 일어나고, 다음 갱신 때 새 이미지가 반영된다. 모니터는 일정 간격으로 갱신되는데, 60Hz면 1초에 60번, 약 16.6ms마다 프론트 버퍼로 화면을 그린다.

그런데 막대를 그리는 도중 다음 위치로 이동한 막대가 화면에 업데이트돼 버려, 비슷하지만 서로 다른 여러 이미지가 한 화면에 동시에 보이는 티어링(tearing)이 생긴다. 원인은 모니터 갱신 도중 프론트 버퍼가 한 번 이상 바뀌는 것, 곧 갱신 도중 버퍼 스왑이 여러 번 일어나는 것이다. 해결책은 모니터가 갱신하는 동안 버퍼 스왑을 막는 것인데, 그러려면 드라이버가 '언제 모니터가 업데이트되는지'를 알아야 한다. 모니터가 갱신될 때 떨어지는 신호가 바로 VSync(수직 동기 신호)다. VSync가 적용되면 신호가 떨어지는 동안 드라이버가 프론트 버퍼를 건드리지 못해 자연스럽게 티어링이 사라지고, 이 펄스가 리프레시 레이트와 일치하므로 리프레시가 언제 어떤 주기로 일어나는지 파악할 수 있다. 한편 VSync를 끈다는 것은 리프레시 레이트를 무시하고 스왑하겠다는 뜻이라, 한 리프레시 사이에 여러 번 스왑하면 마지막 이미지만 보이고 티어링도 날 수 있다. 슈팅 게임에서 흔히 VSync를 끄는 이유는, 켜면 프레임 생성 주기가 리프레시에 맞춰져 입력 처리가 최대 한 프레임 늦어질 수 있어 '먼저 클릭했는데 내가 먼저 죽는' 경험이 생기기 때문이다. 이 지연을 줄이려 고주사율 모니터를 사게 된다는 점도 덧붙인다.

발표의 본론인 프레임 타이밍을 정의부터 브라우저 활용까지 다룬다. 매끄러운 애니메이션을 위해서는 프레임 생성의 시작·종료 시점을 컨트롤하는 것과 주어진 시간 안에 빠르게 이미지를 만드는 것이 필요한데, 이 세션은 프레임 타이밍 컨트롤에 집중한다. 60fps면 약 16.6ms마다 새 프레임이 보여야 하고, 그 시점에 프레임을 만들지 못해 이전 프레임이 다시 보이는 것이 프레임 드랍이다. 프레임 간 간격이 작고 일정해야 부드럽게 보인다. 핵심은 프레임 타이밍을 모니터 리프레시 인터벌에 얼라인해야 한다는 것이다. 단순 타이머(16.6ms)로 프레임을 만들면 리프레시와 어긋나 드랍이 생기므로, VSync 정보를 이용해 리프레시에 맞춰야 한다.

이를 위해 OS별 VSync API를 정리한다. 윈도우는 DWM(GetCompositionTimingInfo, 비스타 이전은 GetMonitorInfo 계열), 안드로이드는 젤리빈에서 도입된 Choreographer의 FrameCallback, macOS는 CVDisplayLink, iOS는 CADisplayLink, 리눅스는 X 윈도우의 GLX 익스텐션과 RandR 프로토콜을 든다. 이들을 콜백 방식과 쿼리(폴링) 방식으로 분류하고, VSync 펄스가 드리프트할 수 있어 한 번 얻은 인터벌을 배수로 쓰면 어긋날 수 있으므로 주기적으로(예: 5초마다) 갱신하되 오버헤드를 고려해야 한다고 짚는다. 마지막으로 브라우저의 활용을 설명한다. 하나는 내부 스케줄링으로, 정확한 데드라인을 설정해 여러 태스크를 한 프레임 안에 처리하도록 최적화한다. 다른 하나는 웹 애플리케이션 스케줄링으로, requestAnimationFrame은 스펙대로 디스플레이 리프레시 레이트에 맞춰 메인 프레임 시작 시점에 콜백을 호출하고, 표준 제정 중인 requestIdleCallback은 메인 스레드가 비는 자투리 시간을 활용하되 남은 시간을 검사해 0이 되면 리턴해 중요한 태스크를 방해하지 않게 한다. 두 API 모두 정확한 프레임 타이밍이 기반이 되어야 스펙대로 동작한다는 결론으로 발표를 맺는다.