Skip to content

Latest commit

 

History

History
80 lines (63 loc) · 8.18 KB

index.md

File metadata and controls

80 lines (63 loc) · 8.18 KB

requestAnimationFrame

1. CPU가 이번 프레임에 필요한 정보를 계산하고 GPU로 전달

  1. 브라우저/애플리케이션 레벨
    • 브라우저의 렌더링 엔진(Blink, WebKit 등)이나 자바스크립트 엔진(V8, SpiderMonkey 등)은 사용자 코드(자바스크립트)와 DOM/CSS 레이아웃 계산 등을 통해 “이번 프레임에 어떤 요소를 어떻게 표시할지” 결정합니다.
    • 예를 들어 requestAnimationFrame 콜백이 도착하면, 그 콜백 안에서 CSS 애니메이션 값을 업데이트하거나 Canvas API로 직접 그리기 코드를 수행하여 “화면에 보여줄 최종 그래픽 정보”를 계산하게 됩니다.
  2. 운영체제(OS) 레벨
    • 브라우저가 이러한 계산 결과(텍스처, 버퍼, 웹 콘텐츠 등)를 GPU에 전달하기 위해서는 GPU 드라이버(DirectX, Metal, Vulkan, OpenGL 등 해당 플랫폼에 맞는 API)를 사용합니다.
    • 이때 OS는 해당 API 호출을 사용자 영역(user space)에서 커널 영역(kernel space)으로 전달해 주고, GPU 드라이버가 실제 GPU 명령어 세트(Command Buffer)로 변환한 뒤 PCI Express(PCIe) 버스 등을 통해 GPU에 전달합니다.
    • 즉, “GPU 전용 버스”라는 표현을 간단히 쓰기도 하지만, 실제로는 OS와 드라이버가 이 과정을 중간에서 관리하고 최적화합니다. OS는 다른 프로세스나 쓰레드의 GPU 접근도 조율해야 하기 때문에, GPU 스케줄링이나 메모리 할당 등을 전담합니다.
  3. 최적화와 전송
    • 드라이버와 OS는 여러 가지 최적화 기법을 사용합니다. 예를 들어 명령어 버퍼(Command Buffer)를 모아서 한꺼번에 전송하거나, 중복된 텍스처를 캐싱하거나, 불필요한 리소스 로드를 지연(deferred loading) 처리하는 식입니다.
    • 이렇게 CPU가 “이번 프레임에 필요한 데이터”를 준비하고, OS가 해당 데이터를 GPU로 안전하게 옮길 수 있도록 제어 및 관리하게 됩니다.

2. GPU는 전달받은 데이터를 바탕으로 실제 렌더링을 수행

  1. GPU 렌더링 파이프라인
    • GPU는 OS로부터 넘겨받은 리소스(텍스처, 버퍼, 쉐이더 프로그램 등)를 바탕으로 버텍스 처리 → 래스터라이즈 → 픽셀 셰이딩 → 프레임 버퍼 출력 과정을 거칩니다.
    • 이 모든 과정에서 CPU의 부담을 줄이고, 병렬처리가 가능한 GPU의 아키텍처를 최대한 활용하여 빠른 렌더링을 수행합니다.
  2. 더블 버퍼링 / 트리플 버퍼링
    • OS와 드라이버 레벨에서, 게임이나 브라우저가 요청한 “표시용 프레임 버퍼(front buffer)”와 “새로 그릴 버퍼(back buffer)”의 개수를 관리합니다.
    • 대부분의 시스템에서 더블 버퍼링이 기본이며, 경우에 따라 트리플 버퍼링을 사용하기도 합니다.
    • 더블 버퍼링이라면, GPU는 back buffer에 새로 그린 결과를 담아두고, vsync 시점에 back buffer와 front buffer를 스왑(swap)하여 사용자 모니터에 표시합니다.
  3. OS의 윈도우 컴포지터(Compositor)
    • 데스크톱 OS(Windows, macOS, Linux 등)에는 보통 윈도우 컴포지터가 있어서, 여러 애플리케이션(브라우저 포함)이 그린 결과를 종합하여 최종 화면을 구성합니다.
    • 이 과정에서도 GPU가 관여하여, “각 윈도우 또는 탭의 렌더링 결과”를 한 장의 화면에 **오버레이(Overlay)**나 합성(Composition) 형태로 표시합니다.

3. 모니터의 수직 주사와 vsync

  1. 수직 동기화(vsync) 시그널
    • 모니터가 새로운 프레임을 표시하기 위해, 위에서부터 아래로 화소를 그리는 수직 주사 과정을 반복하는데, 한 프레임을 끝까지 그린 뒤 다음 프레임을 준비하는 순간을 vsync 시점이라고 합니다.
    • GPU는 이 vsync 시점을 파악하고 있다가, 렌더링이 끝난 back buffer를 모니터로 전송할지 여부를 결정합니다(더블 버퍼링의 스왑).
  2. OS, 드라이버, 브라우저의 동기화
    • OS와 GPU 드라이버는 vsync 정보를 받아, “현재 프레임을 교체해도 되는가?”를 결정합니다.
    • 브라우저는 “렌더링이 끝난 뒤 vsync가 오면 프레임을 교체해 달라”고 요청하거나, vsync 시점에 이벤트를 받아서 requestAnimationFrame 콜백을 트리거합니다.
    • 이런 동기화 덕분에 “화면에 보이는 도중에 프레임이 절반만 바뀌어서 화면이 찢어져 보이는(티어링) 현상”을 최소화할 수 있습니다.

4. 브라우저의 requestAnimationFrame과 vsync

  1. requestAnimationFrame과 vsync 연동
    • 브라우저는 내부적으로 OS에서 받은 vsync 신호를 기준으로 새 프레임을 그릴 준비가 되었는지 체크합니다.
    • 이 시점에 맞춰 requestAnimationFrame 콜백을 호출해 줌으로써, 개발자는 “실제 디스플레이가 갱신되기 직전”에 애니메이션이나 DOM 업데이트를 수행할 수 있습니다.
    • 각 브라우저마다 최적화나 내부 구조는 조금씩 다르지만, 공통적으로 vsync를 활용해 부드러운 애니메이션을 구현한다는 점은 유사합니다.
  2. OS의 스케줄러와 CPU 자원 분배
    • 브라우저가 requestAnimationFrame 콜백을 실행할 때, OS 스케줄러는 브라우저 프로세스(또는 해당 탭 프로세스)에 CPU 시간을 할당해야 합니다.
    • 만약 시스템 전체적으로 부하가 많다면, 브라우저의 콜백 실행 시점이나 빈도가 다소 지연될 수도 있습니다.
    • 그러나 일반적으로 vsync 주기는 60Hz(약 16.67ms)에 맞춰 동작하므로, 브라우저는 약 16ms 주기로 콜백을 실행해 애니메이션을 업데이트하려 시도합니다(고주사율 모니터에서는 더 짧은 주기로 동작할 수도 있습니다).

5. 백그라운드(비활성) 탭에서의 requestAnimationFrame 제한

  1. 탭 비활성화 시
    • 브라우저는 OS 이벤트(윈도우 비활성화, 탭 전환 등)를 확인해 “이 탭은 사용자가 지금 보고 있지 않다”고 판단하면, 해당 탭의 requestAnimationFrame 콜백 호출 빈도를 낮춥니다.
    • 예: 1~2fps 수준으로 크게 줄여서 불필요한 리소스 사용을 줄임.
  2. OS 관점에서의 자원 절감
    • OS는 여러 프로세스의 CPU/GPU 사용량을 전반적으로 모니터링하고 관리합니다.
    • 백그라운드 탭에서의 렌더링 빈도를 낮추면, 전력 소비도 줄고, CPU/GPU 부하도 분산할 수 있어 시스템 전반의 성능에 도움이 됩니다.
    • 특히 노트북이나 모바일 기기에서는 배터리 사용량 절감에도 큰 역할을 합니다.

결론

  1. 설명 전반
    • 브라우저가 자바스크립트/DOM/CSS를 해석하여 CPU로 “이번 프레임에 필요한 데이터”를 계산하고, 이를 OS 수준에서 GPU 드라이버와 연동해 GPU로 전달하는 구조는 현대 브라우저/그래픽 시스템과 일치합니다.
    • GPU는 전달받은 데이터를 실제 픽셀로 렌더링(래스터라이즈, 셰이딩 등)하며, OS와 드라이버는 더블 버퍼링과 vsync를 통해 최적 타이밍에 화면을 갱신합니다.
  2. OS의 역할
    • OS는 GPU 드라이버를 통해 “언제, 어떻게 GPU에 명령을 보낼지”를 관리하고, 여러 프로세스가 동시에 GPU를 사용할 수 있도록 스케줄링합니다.
    • 또한 윈도우 컴포지터를 통해 브라우저뿐 아니라 다른 애플리케이션들이 그린 결과물을 종합해 최종 화면으로 보여주며, vsync 시점에 맞춰 안전하게 화면을 전환합니다.
  3. 브라우저의 역할
    • 브라우저는 requestAnimationFrame 등을 통해 애니메이션 업데이트 타이밍을 제어하고, 백그라운드 탭에서는 프레임 생성을 제한해 시스템 자원을 절약합니다.
    • 내부적으로 CSSOM, Layout, Paint, Composite 단계를 거쳐 “최종적으로 GPU에 전달할 정보를 정리”한 뒤, OS에 GPU 명령을 요청합니다.