이전 글에 이어서, 이번에는 Layer Model에 대한 복습과 함께 CRP 과정에서 발생할 수 있는 하드웨어(GPU) 가속에 대해 조금 더 자세하게, 그리고 이해하기 쉽게 뜯어보려고 합니다.
사실 지난 포스팅에서 어렵고 복잡하게 설명하지 않았나 생각이 들더라구요... 이번엔 최대한 쉽게 설명하려고 노력해보도록 하겠습니다!!
이번 포스팅도 제가 사용하는 크로미움 기반의 크롬 브라우저를 기준으로 두고 설명합니다!! (다른 브라우저의 경우 제가 사용한 예시가 다르게 작동할 수 있습니다!)
(많은 자료들을 통해 최대한 검증하려고 노력하였으나, 그럼에도 틀린 부분이 있다면 언제든지 가차없이 댓글을 남겨주시면 감사드리겠습니다!)
목차
0. Layer Model 복습
이전 포스팅에서 브라우저 렌더링, 혹은 CRP(Critical Rendering Path)라고 불리는 과정에 대해서 간략하게 다뤘습니다.
그 과정에서 Composite과 Layer에 대한 설명을 했었는데요!
이번에는 조금 더 딥하게!! Layer만 집중적으로 다뤄보려고 합니다.
위 사진은 브라우저 렌더링 과정을 나타낸 도식표입니다.
조금 더 간단하게 도식화를 하면 아래와 같습니다.
Update Layer Tree와 Composite는 조금 생소할 수도 있는데, 최신 브라우저에서는 웹 화면을 한 장의 비트맵으로 처리하지 않고 여러 레이어를 나누어서 처리를 하는데, 이 과정에서 필요한 과정이 Update Layer Tree와 Composite입니다.
Update Layer Tree과정에서는 Render Tree의 결과물 중에서 렌더링에 사용되는 부분을 레이어로 만들어주는 과정입니다.
아래서 더 자세하게 확인하겠지만, Paint Layer와 Graphics Layer로 나누어서 레이어를 생성하게 됩니다.
실제로 크롬 개발자도구의 Performance탭에서 아래와 같이 Update Layer Tree 과정을 직접 확인할 수 있습니다.
그리고 이렇게 만들어진 레이어들을 합성하는 부분이 Composite입니다.
이제 아래에서 레이어에 대해 조금 더 자세하게 공부해봅시다!
❗ 아래 사진에서 나와있는 일부 정보는 Slimming Paint에 의해 추후 변경될 가능성이 있다는 점을 미리 말씀드립니다!
- 설명은 이미 변경된 내용으로 진행되니 참고하세요!
Slimming Paint (a.k.a. Redesigning Painting and Compositing)
Slimming Paint (a.k.a. Redesigning Painting and Compositing) Paint team project to re-implement the Blink<->cc picture recording API to work in terms of a global display list rather than a tree of cc::Layers (~aka GraphicsLayer in Blink terminology). It wi
www.chromium.org
0.0. Paint Layer
CPU는 브라우저 렌더링, 즉 CRP 과정에서 생성되는 Render Tree를 이용해서 화면에 표현될 레이어를 생성하게 됩니다.
각 DOM 요소, Layout Object(Render Object)들은 화면에 보다 효율적으로 요소들을 뿌려주기 위해서 레이어형태로 구성될 수 있는데, 이것이 바로 Paint Layer(Render Layer)입니다.
일반적으로 동일한 좌표공간을 가지는 요소들은 같은 Paint Layer에 위치하게 됩니다. (이 말은 Render Object가 동일한 Render Layer에 속하지는 않는다는 말과 같습니다!!)
하지만 필요에 따라 몇 가지 특수조건을 만족하면 추가적인 Layer를 생성하여 별도의 공간에 요소들을 그릴 준비를 하게 됩니다.
그리고 그렇게 만들어진 Paint Layer 요소들은 CRP의 마지막 과정인 Composite에서 합쳐져서 우리 눈에 보여지게 됩니다.
아래는 새로운 Paint Layer가 생성되는 대표적인 조건들을 적어두었습니다. (아래 적은 것 이외에도 다른 요소들이 존재합니다!)
- Root Element인 경우 (Root Element에 대해서는 Root Layer가 생성)
- 명시적인 position 속성값을 가지고 있는 경우 (relative, fixed, sticky, absolute)
- 투명도가 1 미만인 경우
- filter, mask, transform, mix-blend-mode를 가진 경우
- backface-visibility attribute가 hidden인 경우
- auto가 아닌 column-count, column-width 속성을 가진 경우
- reflection 속성을 가진 경우
- 브라우저가 내부적으로 생성하는 경우
0.1. Graphics Layer
그리고 Paint Layer(Render Layer)에서 한 단계 더 나아가서 실제로 화면에 띄워지는 요소들의 출력을 GPU에게 맡기기 위해서 Graphics Layer가 생성될 수 있습니다. (GPU에게는 하나의 렌더링 단위가 됩니다.)
우리가 이번에 집중적으로 다룰 내용은 바로 이 Graphics Layer입니다.
Graphics Layer에 위치한 요소들은 CPU가 처리하는게 아닌 GPU가 처리하게 됩니다.
그리고 이렇게 CPU가 할 일을 GPU에게 위임하여 GPU가 Graphics Layer를 묶어서 하나의 이미지로 만들어 내는 것을 하드웨어 가속, 혹은 GPU 가속이라고 표현합니다.
그렇다면 Graphics Layer가 생성되는 경우는 어떤 경우일까요?
아래는 새로운 Graphics Layer가 생성되는 대표적인 조건들을 적어두었습니다. (아래 적은 것 이외에도 다른 요소들이 존재합니다!)
- video나 canvas 태그를 사용하는 경우
- 하드웨어 가속 플러그인을 사용하는 경우
- 3d transform 속성이 존재하는 경우
- 하드웨어 가속이 된 2D canvas 요소인 경우
- backface-visibility attribute가 hidden인 경우
- transition, animation 속성이 있는 경우
- will-change를 설정한 경우 (opacity, transform, top, left 등..)
그럼 어떤 방식으로 GPU가 해당 레이어를 처리할 수 있냐!!
CPU는 해당 Graphics Layer를 텍스쳐 형식으로 만들어서 GPU에게 전달합니다.
(텍스쳐 형식은 GPU에다가 전달하는 비트맵 이미지라고 생각하시면 됩니다!!)
해당 텍스쳐는 그래픽카드의 램(VRAM)에 올라간 후에 GPU에서 생성한 폴리곤과 메시 구조로 연결되어서(Polygon mesh) 보다 저렴한 비용으로 화면에 요소를 출력할 수 있게 됩니다. (이해가 다소 어려울 수 있으나, 이것때문에 컴퓨터 그래픽스를 공부할 필요까지는 없고!! 간단하게 GPU는 CPU에 비해서 그래픽 처리 속도가 빠르고 애니메이션에 대한 비용이 적다고 이해하고 넘어가셔도 충분합니다!!)
지금까지 내용을 정리하자면, CPU와 GPU가 만들어낸 레이어들을 Composite 과정에서 조합해서 화면에 요소들을 출력하게 되는 것이라고 이해할 수 있겠죠?!
1. 그럼 언제 어떻게 하드웨어 가속을 쓰는데?
1.0. 하드웨어 가속의 등장
하드웨어 가속의 등장은 처음에는 학술적인 목적이었습니다. 처음에는 그래픽 출력의 모든 부분을 CPU가 담당했습니다.
이 때는 하드웨어가 단순히 메모리에 접근해서 화면에 띄우는 역할만을 했었죠.
하지만 개발자들은 어떻게 하면 데이터를 더욱 빠르게 처리할 수 있을까에 대한 고민을 했고, 그래픽 출력과 관련된 부분을 하드웨어에게 맡기고, 나머지 부분만 CPU를 이용해 처리한다면 작업을 훨씬 빠르게 처리할 수 있지 않을까라는 생각에 도달하게 되었고, 이것이 하드웨어 가속의 등장으로 이어졌습니다.
그러다가 게임, 3D와 같은 대량의 연산을 필요로 하는 작업이 등장하게 되었고, 그래픽 처리에 대한 필요 시간이 점차 커지기 시작했습니다.
이제는 하드웨어 가속이 개발자만의 영역이 아닌 일반적인 컴퓨터 사용자에게까지 필요해지게 된 것이죠.
다시 요약하자면, 하드웨어 가속은 CPU에서 처리해야만 했던 요소들을 GPU(하드웨어)가 처리하도록 명령하여 기존에 비해 훨씬 빠른 속도로 같은 작업을 처리할 수 있도록 하기 위해 등장했습니다.
1.1. 하드웨어 가속 사용 예시
하드웨어 가속을 사용하는 방법은 Graphics Layer를 생성하는 방법과 동일합니다.
가장 흔하게 사용되는 방법이 바로 translateZ(0) 옵션인데, z-index에다가 0을 주게 되면
- 3d transform 속성이 존재하는 경우
에 걸려서 Graphics Layer가 생성됩니다.
어떻게 보면 강제로 하드웨어 가속 속성을 부여하는 것이죠.
네이버 홈페이지에서 예시를 들어보도록 하겠습니다.
기존에는 사용자의 프로필 사진 부분의 레이어를 따로 분리해 내기 위해 임의로 translateZ(0) 옵션을 부여했고, 그 결과 별도의 레이어로 분리가 된 모습을 확인할 수 있습니다!
이쯤에서 다시 한번 살펴봐야 할 부분이 있습니다.
Graphics Layer의 생성 조건을 다시 살펴보면, 일반적으로 해당 DOM 노드가 주변의 노드와는 별도로 렌더링되어야 빠른 경우임을 확인할 수 있습니다.
opacity를 담당하는 layer에 transition을 준다고 생각해보면, 해당 부분은 별도로 처리되어야 다른 요소에 영향을 받지 않고 보다 효율적으로 처리할 수 있겠죠?
video 태그 역시 매번 변하는 이미지를 화면에 띄워줘야 한다는 점에서 별도로 처리되어야 효율적으로 처리할 수 있을 것입니다.
브라우저는 CSS 속성중에서 GPU가 처리했을 때 훨씬 효율적일 것이라고 생각한 부분을 GPU가 처리할 수 있도록 미리 설정해두고, 우리 개발자들은 그것을 그대로 따라서 사용하면 된다는 것이겠죠?
1.2. 하드웨어 가속 사용 시 주의점
하지만 단순히 CPU가 하던 일을 그대로 GPU가 처리하게 하면 모든 문제가 해결되는 것은 아닙니다.
물론 하드웨어 가속을 브라우저에서 레이어 분리를 통해 쉽게 적용할 수 있도록 만들어 놓았지만, 이로 인해 발생할 수 있는 side effect에 대해서 이해하지 않고 사용한다면 성능의 이점을 제대로 살리지 못할 수 있기 때문입니다.
먼저 하드웨어 가속을 통해 화면 출력을 효율적으로 처리하기 위해서 레이어를 분리하여 생성해야 합니다.
이 과정에서 추가적인 메모리가 발생할 수 있습니다.
또한 CPU와 GPU가 처리해야 하는 데이터와 프로그램은 각각 분리되어 있기 때문에 메인 메모리(RAM)에 있는 요소들을 비디오 메모리(VRAM)으로 전달하는 과정 역시 필요합니다.
전달하는 과정에서 발생할 수 있는 시간을 고려해야합니다.
또한 VRAM이 부족하다면 GPU가 정상적으로 처리하지 못하는 상황이 발생할 수도 있습니다.
따라서 기기에 따라 하드웨어 가속이 적용되거나 적용되지 않게 만드는 것도 고려할 필요가 있습니다.
그리고 DOM 트리 자체를 변경하는 일이 많아진다면 GPU의 Layer만으로 해결할 수 없기 때문에 하드웨어 가속으로 인한 cost만 누적되는 상황이 발생할 수 있습니다.
그렇기 때문에 우리는 하드웨어 가속을 단순히 사용만 하면 성능 최적화를 할 수 있다고 생각해서는 안되고, 다양한 부분을 고려해서 사용해야합니다.
2. 정리
지금까지 최근 브라우저에서 어떻게 레이어를 이용해서 화면에 요소들을 띄우는지, 그리고 하드웨어 가속이 무엇이며 어떻게 동작하고 사용할 수 있는지에 대해 알아보았습니다.
하드웨어 가속을 이용한 최적화를 통해 사용자에게 더욱 빠르고 부드러운 화면을 보여줄 수 있지만, 잘못 사용한다면 예상치 못한 상황에 맞닥뜨릴 수 있다는 것도 깨닫게 되었습니다.
그렇기 때문에 단순히 "이런 방법을 사용하면 UX를 개선할 수 있다" 라고만 단순하게 이해하고 넘어가기 보다는 브라우저의 렌더링 과정이 어떻게 진행되는지, 어떤 원리로 하드웨어 가속이 최적화를 도울 수 있는지에 대해 확실하게 알고 넘어간다면 조금 더 좋은 웹 페이지를 만들 수 있지 않을까 생각합니다.
지금까지 간단하게 설명한 내용 이외에도 더 다양한 요소가 CRP 과정에 영향을 끼치고 UX에도 큰 영향을 줄 수 있습니다.
또한 효율적인 방법이 합쳐진다고 반드시 더 효율적으로 변하는 것은 아닐 수 있습니다.
앞으로도 렌더링 성능을 끌어올리기 위한 다양한 방법들에 대해 더 공부해보고 실전에 적용해볼 수 있도록 더욱 노력해야겠습니다!!
3. 참고자료
프론트엔드 개발자를 위한 크롬 렌더링 성능 인자 이해하기
하드웨어 가속은 프론트엔드 개발자에게 있어서 분명 축복입니다만 한편으로는 잠재적으로 새로운 문제를 발생할 수 있는 발생할 수 있는 영역이기도 합니다. 하드웨어 가속에 의한 렌더링 성
cwdoh.com
Front-End Performance Optimization with Accelerated Compositing Part 1
Optimizing the performance of any webpage is crucial. This blog gives an insight into the overall process of reforming the whole display and layout of any webpage with accelerated compositing.
www.alibabacloud.com
FrontEnd 개발자가 수행하는 성능 개선 작업
Network Panel Timeline Panel, Layer Panel, Rendering Panel Profile
sculove.github.io
웹 성능 최적화에 필요한 브라우저의 모든 것
NAVER Engineering | 웹 성능 최적화에 필요한 브라우저의 모든 것
tv.naver.com
최근댓글