Empfohlen
Weitere ähnliche Inhalte
Ähnlich wie Browser Rendering
Ähnlich wie Browser Rendering (20)
Mehr von Wonjun Hwang
Mehr von Wonjun Hwang (20)
Browser Rendering
- 2. 렌더링 지방을 정제하여 기름을 추출하는 작업 3차원 모델을 2차원 모델 형태로 바꾸어 표현하는 작업 문서를 작성하고 해석하여 화면에 그려주는 작업
- 3. 브라우저
- 4. 브라우저
- 6. 브라우저 구성요소 User interface Browser Engine Render Engine Ui bankend Js engine network Data storage 다양한 운영체제에서 실행 되는 브라우저별 일반적인 UI 인터페이스를 제공 Ui bankend
- 7. 브라우저 구성요소 User interface Browser Engine Render Engine Ui bankend Js engine network Data storage Cookie, Web Storage, IndexedDB, Cache Data storage
- 8. 브라우저 구성요소 User interface Browser Engine Render Engine Ui bankend Js engine network Data storage Http protocol을 통해 Resource를 browser에 표 시 network
- 9. 브라우저 구성요소 User interface Browser Engine Render Engine Ui bankend Js engine network Data storage Javascript code를 해석 및 실행 Js engine
- 10. JS 엔진
- 12. 유저 인터페이스 사용자가 요청한 페이지를 제외한 모든 부분
- 13. 브라우저 엔진 User Interface와 Rendering engine 사이의 동작 제어
- 14. 렌더링 엔진 Webkit Gecko Blink servo
- 15. 렌더링 엔진 동작 방식 Dom tree Render tree layout painting Html parsing css parsing Main thread reflow repaint
- 16. 렌더링 엔진 동작 방식 commit tiling raster draw Compositor thread
- 17. DOM Tree
- 18. CSSOM Tree
- 19. Render Tree
- 20. Layout
- 21. Paint
- 22. Compositing
- 23. Compositing
Hinweis der Redaktion
- 렌더링이라는 개념이 화면에 사용자가 알 수 있도록 그리는? 개념으로만 어렴풋이 알고 있었다.. 이 기회에 확실히 알아볼까.. 웹성능 최적화, 웹 호환성, 보완, 디자인에 도움이 된다.
- 렌더링이라는게 여러 방면에서 쓰이는 듯함. 동물의 지방에서 기름을 추출할때나.. 악보를 음악으로 추출할떄나.. 재활용 처리할떄나… 다방면에 의미가 있는게 신기하네..
- 브라우저의 종류 이것말고도 진짜 많은듯.. 인터넷에서 웹 서버의 모든 정보를 볼 수 있도록 하고, 문서 검색을 도와주는 프로그램~
- 크롬이 압도적이긴 하네..
- # 브라우저 동작방식 URI와 URL의 차이~ㅎ Identifier <-> Location 원하는 정보에 도달은 식별자(Identifier)가 필요! 과거에는 naver.com/index.html 형식으로 되어있다보니 구분이 되었지만 현재는 사용이 보다 복잡해졌기 때문에 서로 같은 개념이라고 봐도 무방하다 중요한 포인트는 Location은 자원의 위치!, Identifier는 자원의 식별자정도로만 이해하고 가면 무방할듯 ============== Html, js, css 주고 받음 Server은 express나 apache, nginx등
- #브라우저 구성요소 렌더링 엔진(=레이아웃 엔진) User interface: 브라우저 열었을때 상단에 있는 주소 표시줄이나 버튼들 Browser engine: user interface와 rendering engine 사이의 동작을 제어 (주소창 입력 -> 브라우저가 입력값에 대한 응답을 가져올 수 있도록 렌더링 엔진을 컨트롤함.) Rendering engine: request content를 보여줌(이미지 등), html,css, js를 파싱하여 화면에 표시 Server단에서는 webserver, os, hardware Gekco -> 파이어폭스 Blnik -> 크롬
- IndexdDB는 대용량~ Cache Storage는 말그대로 자원 캐싱용~ Web storage는 데이터 저장용~ Cache, web는 목적이 달라!
- 브라우저에 입력한 URL 주소를 처리하여 DNS 서버에서 조회, HTTP 요청 및 응답 처리 및 쿠키, 캐시 관리, CORS 보안 정책 관련 작업
- Js engine 혹은 js parser, 해석기로 불림 예시로는 다음과 같다 10page
- V8은 크롬이나 node Spider monkey는 모질라 파이어폭스 Javascriptcore는 애플에서 (b3 jit으로 대체됨) B3 jit => Balanced three-tier just-in-time 앞서 봤던 공통적인 브라우저 구성요소들을 브라우저 별로 보자면 다음과 같다 11page
- #브라우저 구성요소 렌더링 엔진(=레이아웃 엔진) User interface: 브라우저 열었을때 상단에 있는 주소 표시줄이나 버튼들 Browser engine: user interface와 rendering engine 사이의 동작을 제어 (주소창 입력 -> 브라우저가 입력값에 대한 응답을 가져올 수 있도록 렌더링 엔진을 컨트롤함.) Rendering engine: request content를 보여줌(이미지 등), html,css, js를 파싱하여 화면에 표시 Server단에서는 webserver, os, hardware Gekco -> 파이어폭스 Blnik -> 크롬 정확한 구성요소가 정리된 부분은 없다.(지속적으로 변화하기 때문)
- #브라우저 구성요소 렌더링 엔진(=레이아웃 엔진) User interface: 브라우저 열었을때 상단에 있는 주소 표시줄이나 버튼들 Browser engine: user interface와 rendering engine 사이의 동작을 제어 (주소창 입력 -> 브라우저가 입력값에 대한 응답을 가져올 수 있도록 렌더링 엔진을 컨트롤함.) Rendering engine: request content를 보여줌(이미지 등), html,css, js를 파싱하여 화면에 표시 Server단에서는 webserver, os, hardware Gekco -> 파이어폭스 Blnik -> 크롬
- Browser engine: user interface와 rendering engine 사이의 동작을 제어 (주소창 입력 -> 브라우저가 입력값에 대한 응답을 가져올 수 있도록 렌더링 엔진을 컨트롤함.) 큰의미의 브라우저 엔진이고 렌더링 엔진은 이안에 속해있음 사실 큰차이는 없다.. 고놈이 고놈이다..
- Webkit은 safari(chrome도 있었으나, blink넘어감 2014) Gecko는 mozila firefox blink 는 chrome Servo engine은 모질라재단에서 하고있다가 리눅스 재단으로 이관(2017)되었고 2023년부터 다시 개발 시작함(rust로 작성)
- 다음으로는 렌더링 엔진 동작방식에 대해 설명해드릴건데요. Blink 기준입니다 돔 트리 구축(dom tree) -> 렌더 트리 구축(render tree) -> 렌더 트리 배치(layout) -> 렌더 트리 그리기(painting) 파싱하는 과정에서 바이트 코드들을 문자열로 변환하고 그걸 토큰 or 노드로 변경함 Html를 파싱하여 돔을 생성!(dom node로 변환~) 생성한 돔을 Css를 파싱하여 스타일 요소와 같이 render tree 생성~ 즉! Render tree는 객체들의 계층 구조와 스타일, 레이아웃 정보를 가지고 있다! (레이아웃 계산의 최적화를 위해 필요한 정보만 가지고 있음!) Layout 단계에서는 render tree를 돌면서 각 노드의 위치와 크기를 계산함 (브라우저의 gpu 사용해서 ~) Painting 단계에서는 render tree를 돌면서 css 정보에 따른 ui backend를 이용하여 화면에 표시한다! 이 그림은 크로미움의 blink engine 기준 ㅇㅇ
- Commit => 렌더 트리의 레이아웃과 페인트 작업을 비동기적으로 실행 Tiling => 타일로 분할하여 타일 단위로 레이어를 분리 Raster => 타일에 그려진 그래픽을 비트맵 이미지로 래스터화함. 레이어의 투명도, 필터, 마스크 적용 Draw => 래스터화된 이미지를 화면에 그림 브라우저 엔진마다 다르지만 무조건 일어나는 단계는 아님 좀 더 자세히 보자~
- 토큰은 브라우저별 약속된 값을 의미
- Script, meta tag등 출력에 반영되지 않늩 태그들은 생략~ 숨겨지는 노드들도 마찬가지~ 웹 접근성이랑 연관이 있다.. Why ? 스크린 리더기에서는 렌더 트리에 없는 태그들을 읽을 수 없기때문..
- 이어서, layout 단계 LayoutBlock Flow는 블록 레벨 요소를 처리하는 방법임. 블록 요소들의 레이아웃을 계산하고 배치함. (크기부터 계산하고 그다음 위치 잡음 !) 페인트 레코드를 생성 !
- Painting 단계!(어떤 순서로 그릴지 판단함) z-index같은것이 있기때문 페인트 레코드를 생성한걸 가지고 화면에 그리는 작업 ! 레이아웃에 영향을 행사하는 style! Width, height, position, border, display 페인트에 영향을 행사하는 style ! color, visibility, text-decoration, background-position, outline-color, outline-style, outline-width, background-size, border-style, background, background-image, background-repeat, outline, border-radius, box-shadow Transform, opacity는 gpu 관여 AND DOM tree에 변경하지 않도록 설계되어 있음 크기, 위치가 바뀌면 레이아웃부터 다시하고 수치를 변화시키지 않는 스타일 변경은 페인팅부터! 타일의 비트맵을 생성하고 gpu로 전송~
- # 옛날방식 페인팅 작업 = 정보를 화면의 픽셀로 바꾼다 이걸 바로 래스터화(rasterizing)라고 함 ㅇㅇ 위예제는 화면에 보이는 영역을 스크롤했을때 래스터된 프레임을 움직이고 그만큼 부족한 부분을 추가적으로 래스터링하여 채움!
- 여러 레이어로 나눈다음 각각 래스터화하여 컴포지터 스레드에서 페이지를 합성함 위 예제처럼 스크롤 시 프레임을 합성함 https://computermuseum.nexon.com/ 이걸로 설명