ETC - 컨트리뷰톤 크로미움 오프라인 세미나 모임 정리 (고병권, 방진호 멘토님)

ETC:

컨트리뷰톤 크로미움 오프라인 세미나 모임 정리 (고병권, 방진호 멘토님)

1. Let’s get to be familiar chromium (고병권 멘토님)

| git 명령어 관련

Git new-branch ‘branch-name’ => 크로미움 프로젝트에서만 있는 명령어 (권장)

• create new branch
• switch to new branch
• set upstream
• 브랜치당 cl 하나

Git checkout -b  ‘branch-name’

• 위와같이 체크아웃으로 그냥 브랜치를 만들면 업스트림이 없음)
• 업스트림: 리모트 서버와 연결이 되어있느냐 없느냐

Git rebase-update

• 리베이스 하고 동일한 브랜치 삭제까지 해줌
• 이걸 쓰는 사람들은 git new branch로 했을때만 사용
• 안그러면 다삭제 될수도 있음 (git new branch로 안했을시)
• rebase
• arrange branch

Git branch -avv 

Git cl format

• 자동 포맷팅

Git cl patch [patch number]

• 컨플릭트 할때 사용
• 체리 픽 생각하면 됨

Git cl issue (게릿의 issue number)

• Git cl issue 0 -> 이슈 없애는 방법
• 이슈가 꼬일수 있음

| github과 gerrit의 차이점

• Origin/master 기준으로 코드수정한게 한번에 올라감
• 단위가 patch 임
• 어멘드로 하는게 좋음

| description 관련

Description Rule

-80바이트

-터미널 옆에 간격이 8바이트라서, 72바이트

Summary of change

내용

Bug:버그번호

OWNER

• 24시간이 (working day 기준) 지나면 gentle ping 날리면 됨

| BUILD 관련

• 변경한 파일의 build.gn 을 찾음
• gn ls out/Debug/ > out.txt 타겟팅 하는 파일들이 나옴
• ninja -c out/debug 타겟팅 하는 폴더

크로미움에서 중요한 디렉토리 세개

• chrome
• content
• third-party/blink
• blink -> renderer-> modules 파일시스템
• blink -> renderer -> core (여기서 구현)

| 테스트 관련

• 블링크에서 테스트관련을 고치면 ninja -c out/debug blink_tests
• ninja -c out/debug (content,base)_unittests -> content 밑의 모든 unittest들 테스트
• ninja -c out/debug unit_tests (크롬만 text 명령어가 다름)

| TERM

• IMHO
• WUP
• AFAIK

| 리뷰

• 리뷰달면 DONE으로 해야함

2.CHROMIUM / BLINK (방진호 멘토님)

| 서버-client

• Client -sever 소켓(인터넷) 으로 연결
• Chromium (client) <-> apache (server)

| What’s chromium

> Multiprocess architecture

• process  (독립된 메모리 공간) vs thread (메모리 공유)
• 보안때문에 중요함, -> 멀티 프로세스를 사용하는 이유
• 네이버 창을 띄우고, 구글창을 띄우면 다른 프로세스 (네이버에서 일어난일은 구글창에서 일어난일에   상관x) 다른 프로세스에 영향 x ,만약 멀티스레드라면 영향을 서로 끼침
• 완벽한 렌더링 엔진은 없음, crbug사이트가면 알수 있듯이.
• 인터넷익스플로러는 싱글 프로세스..
• 크롬의 프로세스: 브라우저 프로세스(os ui,외부와 통신) , 렌더러 프로세스 (플랫폼 독립적) ,gpu 프로 세스..etc, 인터프로세스 커뮤니케이션
• (렌더러 프로세스에서 브라우저 프로세스에게 파일을 읽어달라고 요청)

> Browser internal1

리소스가 들어오면 크로미움 엔진을 통해 구글 창이 나오게 해준다.

loading -> parsing -> layout -> js execution -> painting ->ui update

[parsing]

blink -> render -> core (여기서 구현)

• (블링크 엔진에서 하는 일(어떻게 그릴지), js는 v8엔진에서 함)    
• html parsing
• css parsing

• dom트리 생성중 style 태그를 만나면, cssom tree 생성(dom트리의 복사본, Dom 트리와는 별개)
• 최종적으로, render tree(paint tree) 생성 -> 눈에보이는 것만 (ex: display: none인것은 안보여줌)
• Dom -> cssom -render

[layouting]

어떻게 그릴지는 render tree에는 담겨있는데 어떤위치에 어떤 사이즈로 그릴건지 정해주는 단계

layouting은 언제발생?

• 첫번쨰 dom 생성시
• html chunk (by script)
• html element 크기 위치 변경
• sub-resource(이미지)가 로드 될때

[layering]

render트리를 돌면서 어떤걸 먼저 그릴지에 대한 painting order

layer의 생성 조건

• root object
• css position property가 명시적인 경우
• overflow, alpha mask, reflection
• css filter 사용
• gpu사용 canvas
• video태그 (애초에 레이어를 분리했음, 역동적 애니메이션)

[painting]

크롬에서 쓰는 그래픽 라이브러리: skia -> OpenGL 이를 통해 painting

cs.chromium.org => 코드 찾는것

> Browser internal2

• paint는 브라우저 성능에 가장 큰 영향을 미침
• gpu가속의 장점
• 텍스쳐를 가지고 이미지를 빠르게 그림
• sw렌더링은 느림

> Browser internal3

V8 엔진 -> 자바스크립트를 인식하는 엔진

• 자바스크립트와 블링크 엔진이 어떻게 연결되느나 (브라우저 입장)

document.getElementById();

• js파일 해석을 요청
• Chromium loader -(dom parwsing)-> blink engine -(js evaluate)-> v8엔진

V8 바인딩

• chromium에서 v8과 blink를 연결