Firefox의 렌더링 갱신 영역과 겹치는 반투명 png 배경 영역의 면적에 따른 렌더링 속도 차이 문제

[daybreaker]

(이 글은 '시작 속도', '구동 속도'와는 관계 없습니다)

Firefox 3.5, 3.5.1 버전 모두 윈도우용 버전에서 렌더링 엔진에 심각한 속도 문제가 있는 것 같습니다. 파이어폭스의 창 크기가 클수록 렌더링 속도가 급격히 저하되는데요, 컴퓨터나 사이트에 따라 차이는 있지만 회사에서 쓰는 AMD Athlon 7750 듀얼코어 + ATI 3200HD 내장그래픽 + 19200x1080 해상도 모니터 + Windows XP SP3 컴퓨터에서 http://me2day.net/daybreaker 페이지를 열었을 때 왼쪽의 메뉴바에서 마우스를 움직여보면 마우스 포인터가 움직이는 속도를 전혀 못 따라옵니다. 근데 창 크기를 거의 그 메뉴만 보일 정도로 작게 줄이면 아주 빠릿빠릿해집니다. 창 크기가 중간 이상일 때 jQuery UI 라이브러리를 이용해 자바스크립트로 dialog를 띄워도 이를 드래그하면 거의 봐주지 못할 수준이네요.

비슷한 해상도의 모니터에 E6600 + 9800GTX+ + Vista 64bit SP2 쓰는 개인 데스크탑에서도 창 크기가 작을 때와 클 때의 차이가 적긴 해도 분명히 차이가 나는 걸 느낄 수 있습니다.

물론 크롬은 두 환경 모두에서 화면 크기와 상관 없이 아주 빠릅니다.;;

신기한 건 MacOS X에 깔아서 쓰고 있는 파이어폭스에서는 이런 문제가 전혀 없다는 겁니다. -_-;; 크롬이나 사파리보다 살짝 느릴 뿐 불편하다는 느낌은 없습니다.

저만 겪는 문제인지, 아니면 윈도우 파이어폭스 사용자분들도 공통적으로 겪는 문제인지 궁금합니다. 이것 때문에 jit 관련 옵션 껐다켰다 해보고 color management도 껐다켰다 해봤지만 그것에 영향받는 건 아닌 것 같습니다.

ps. Firefox 3.0도 그런가 설치된 컴퓨터를 찾아서 해봤는데 역시 비슷하군요. -_-;; 원래 그런 건가요;

ps2. 글의 의도를 명확히 하기 위해 제목을 수정했습니다.

[daybreaker]

이 문제를 좀더 자세히 살펴보기 위해 Firebug를 이용해보았는데요, 미투데이의 경우 화면의 대부분을 차지하는 div element(CSS Selector로 따지면 body #mystream #container .section_wrap)를 지워버렸더니 메뉴 위에서 마우스 포인터를 왔다갔다 움직일 때 생기는 느려짐 문제가 완전히 싹 사라졌습니다.

그 div 내부의 div.content_wrap element에 먹혀 있는 배경 이미지(/images/stream/bg_mystream_repeat_y.png)가 반투명 png 파일인데, 이 background 속성을 해제하기만 해도 상당한 성능 향상이 있는 것을 확인할 수 있었습니다.

즉, 살짝 겹쳐있는 요소가 반투명 png 배경을 가지고 있다면 해당 요소까지 통째로 다시 렌더링하기 때문에 느려지는 것 같습니다. 해당 요소가 창 크기만큼 크니까 창 크기가 바뀌면 렌더링 속도도 바뀌었던 것 같구요.

이 현상이 맥용 Firefox에서는 왜 발생하지 않는지(혹은 않는 것처럼 보이는지) 모르겠지만 윈도우용에서는 정말 엄청난 차이를 보입니다. 이거 버그질라에 보고해야 할까요?

ps. 아마도 이전 버전의 Firefox부터 계속 문제가 있던 부분 같습니다만 본격적으로 반투명 png 배경을 쓴 사이트가 거의 없었기 때문에 잘 나타나지 않았다가 이번 미투데이 개편 이후 자주 가는 사이트다보니 크게 두드러지게 느껴지는 듯합니다. 앞으로 이런 일이 더 많아질 수 있을 것 같네요.;;

ps2. 트위터 사이트에서도 비슷한 문제가 나타났었는데요, 글쓰기 입력창에 타이핑하면 매우 느려지는 형태였습니다. (미투데이도 마찬가지입니다) 그런데 요즘 괜찮아져서 다시 살펴보니 gif 또는 moz-border-radius를 사용해서 처리해놨네요;

ps3. jQuery UI의 dialog가 느린 것도 아마 modal로 띄우면 화면 전체에 반투명 div element를 씌우기 때문이 아닐까 싶습니다.

ps4. ...혹시나 해서 크롬에서도 창 크기를 가로 세로 다양하게 바꿔가며 테스트해봤는데, 워낙 빨라서 불편하지는 않지만 크롬도 같은 양상의 속도 저하 문제가 나타납니다. 역시 세로 크기 변할 때만 속도가 차이나는 걸로 봐서 같은 문제인 듯합니다. -_-;;;

ps5. 맥용 파이어폭스도 마찬가지 문제가 있습니다만 크롬처럼 기본적으로 상당히 빨라서 불편이 느껴지지 않는 수준인 듯합니다.

ps6. 진짜로 속도가 거의 변하지 않는 건 사파리인 듯하네요. -_-;;;;

[hwang]

코드를 수정하신 건지는 모르겠지만, 제 경우에는 속도 문제가 없네요.
혹 사용중이신 확장기능 중 하나가 문제가 있는 건 아닐까요?
안전 모드로 한 번 테스트해 보심이...

* 사용 환경: AMD 셈프론 2800+, WinXP SP3, Firefox 3.5.1

[feynman]

제 경우도 그 사이트 들어가봐서 테스트 해보니 별 이상이 없는데요.

*사용환경: 맥북 2008early 모델 CPU:인텔 코어2듀오 T8300 메모리: 2GB 운영체제:윈도7 빌드7100
Firefox 3.5.1

[daybreaker]

코드를 수정하신 건지는 모르겠지만, 제 경우에는 속도 문제가 없네요.
혹 사용중이신 확장기능 중 하나가 문제가 있는 건 아닐까요?
안전 모드로 한 번 테스트해 보심이...

* 사용 환경: AMD 셈프론 2800+, WinXP SP3, Firefox 3.5.1

흠, 지금은 밖에 나와있는지라 테스트할 수가 없지만... 월요일에 회사 돌아가면 안전모드로도 한번 해봐야겠네요. 하지만 제 생각엔 확장기능보다는 렌더링 엔진 자체의 특성에 가까운 문제 같습니다.

그리고 두번째 글에 단 ps들을 보시면 아시겠지만, 파이어폭스뿐만 아니라 크롬도 같은 문제가 있고 나중에 추가로 테스트해본 바로는 IE도 같은 문제가 있습니다. 하지만 그 중에서 윈도우용 파이어폭스가 유난히 두드러지게 느려집니다. 나머지는 차이는 있어도 사용하는 데는 전혀 불편하지 않은 수준이죠. (여기서 속도 테스트는 마우스 포인터를 메뉴 위로 빠르게 왔다갔다할 때 메뉴의 하이라이트 속도가 마우스 포인터의 속도를 따라오는지로 한 것이라서, 일반적인 사용에는 지장이 없더라도 미묘한 속도 차이가 나는 경우를 얘기합니다. 직접 보여드리기 전에는 말로 설명하기가 좀-_-)

추가 : 안전모드로도 해봤는데 동일합니다.

[daybreaker]

제 경우도 그 사이트 들어가봐서 테스트 해보니 별 이상이 없는데요.

*사용환경: 맥북 2008early 모델 CPU:인텔 코어2듀오 T8300 메모리: 2GB 운영체제:윈도7 빌드7100
Firefox 3.5.1

제가 맥오에스 사용하는 환경이 2008년 1월에 구입한 맥북프로입니다. 윈도7은 아직 한번도 안 써봐서 잘 모르겠네요; Vista SP2 환경에서 쓰는 파이어폭스도 사용 상의 문제는 없을 정도지만 여전히 속도 차이가 있습니다.

[짐꾼]

윈도7에서 불여우, 오페라, 사파리, 크롬, IE로 해봤는데 지극히 정상인데요..
지금 인코딩중이라서 CPU사용율이 95프로 이상인데도 정상입니다.
인텔 울프데일 E6300@3.5G, 4G램, 1920x1200 해상도입니다.

[daybreaker]

윈도7에서 불여우, 오페라, 사파리, 크롬, IE로 해봤는데 지극히 정상인데요..
지금 인코딩중이라서 CPU사용율이 95프로 이상인데도 정상입니다.
인텔 울프데일 E6300@3.5G, 4G램, 1920x1200 해상도입니다.

음, 저도 XP SP3에서 두드러지게 속도 저하가 발생하는 경우를 제외하고 다른 환경에서는 모두 '정상' 범주에 듭니다만, 제가 지적하는 부분은 렌더링 영역의 크기 변화에 따른 속도 차이 그 자체입니다. 동영상으로 찍어서 보여드리기도 힘들고 말로만 설명하니 전달이 잘 안 되는 것 같네요.;;

모니터 해상도가 점점 커짐에 따라 반투명 png를 배경으로 까는 경우 해상도에 대한 scalability 문제가 발생할 수 있기에 미리 지적하고자 하는 것입니다. 필요한 부분만 갱신한다면 속도 차이가 없어야 할 것으로 생각되는데 다른 배경 부분의 렌더링 면적에 따라 속도 차이가 발생한다는 것이죠. 다른 분들의 경우에도 불편하지 않은 것과 속도 차이를 구분해서 테스트했을 때도 그런가 알고 싶습니다.

다시 조건을 명확히 적어보겠습니다.

1. 반투명 png를 배경으로 사용하는 큰 크기의 요소가 있음.
2. 그 요소와 일부 겹치는 다른 요소가 있음. (예: 마우스 롤오버 시 이미지나 색이 바뀌는 메뉴)
3. 겹치는 그 요소가 갱신될 때 반투명 png를 배경으로 사용하는 요소도 함께 전체가 갱신되어, 그 요소가 보여지는 면적에 따라 렌더링 속도의 차이가 발생함. 가장 이상적인 구현이라면 메뉴와 겹친 부분만 갱신되어야 하고, 그렇다면 속도 차이가 발생하지 않아야 함.
4. 대부분의 사용 환경에서 그 속도 차이는 매우 미미하여 실제 사용에 아무런 불편이 없으나, 모니터 해상도가 아주 큰 경우나 쓰레드 첫글처럼 특정한 경우에는 속도 차이가 두드러지게 나타나 불편을 초래할 가능성이 있음.
5. 참고로 겹치는 것뿐만 아니라 내부에 들어있는 요소도 비슷한 영향을 주는 것 같음.

그래서 여기서 제가 원하는 것은...

* 반투명한 배경을 가질 경우 그 아래의 내용이 바뀌면 화면에 다시 그려야 하기 때문에 전체 갱신이 가장 간편하고 버그를 줄일 수 있는 구현이지만, 일부 경우에 심각한 속도 저하가 발생하는데 그런 경우에 왜 그 환경에서만 그런 문제가 발생하는지 알고 싶고, 근본적으로 이 문제를 해결하려면 게코 엔진 자체의 렌더링 로직이 개선되면 좋을 것 같다는 것이 제 생각입니다. 저와 같은 '특정 케이스'가 더 많이 발생한다면 버그질라에 공식적으로 보고할 생각이고, 이를 위해 의견을 수렴하고자 합니다.

곧 미투데이뿐만 아니라 일반적으로 이 문제를 재현할 수 있는지 테스트하는 별도의 페이지를 하나 만들어보겠습니다.

[daybreaker]

이번 주부터 회사에서 인턴 마치고 나가신 분이 있어, 위에서 얘기한 22인치 1920x1080 해상도 모니터에 17인치(1280x1024) 모니터를 추가했습니다. 22인치는 DVI로 연결되어 있었고, 새 17인치는 VGA로 연결했습니다.

...그랬더니 파이어폭스 렌더링 속도가 빨라지네요?

새로 추가한 모니터를 왼쪽에 두고 바탕화면 확장해서 쓰는데, 파이어폭스 창을 어떤 쪽에 놓아도 똑같이 속도가 빨라졌습니다. 예전엔 3.5 업데이트 후 처음 나오는 안내 페이지의 동영상도 매우 끊겨서 못 볼 정도였는데 오히려 지금은 아주 잘 재생됩니다. 미투데이도 속도 차이가 아주 없어진 건 아니지만 예전처럼 버벅이는 느낌 없이 사용 상의 불편이 없을 만큼 빨라졌습니다.

아마도 특정한 해상도 혹은 그래픽 환경의 영향을 받는 부분이 있는 듯합니다. 메인보드 내장그래픽으로 ATI 3200HD 쓰는데 그래픽 드라이버나 다른 쪽 문제일까요?

버그 재현 페이지 만들려고 했는데 완전 어이없게 해결(?)되는군요. 아놔....

ps. 참고로 아직 3.5.2 업데이트 안 했습니다.

ps2. 어제 듀얼모니터 처음 세팅할 땐 DVI 쪽이 primary, VGA 쪽이 secondary로 잡혔는데, 오늘 와서 켜보니 VGA가 primary, DVI가 secondary로 잡히는군요. 내부적으로 secondary인 것을 primary로 쓰려다 문제가 생겼던 게 아닐까 싶습니다. 궁금한 건 크롬은 전혀 문제 없었는데 왜 파이어폭스만 유독 심하게 속도 차이가 발생하는가 하는 점이네요. (참고로 같은 시기에 정확히 같은 사양으로 컴퓨터를 맞춘 다른 자리에서는 아직도 제가 말한 문제가 발생하고 있습니다.)

[daybreaker]

이 문제, 모질라진에도 보고되어 있었군요!

http://forums.mozillazine.org/viewtopic ... 8&t=807075

결론은 불안정한 ATI 그래픽 드라이버와 파이어폭스 엔진의 합작품인 듯합니다. 정확한 원인은 알 수 없는 듯하네요. 근데 크롬은 멀쩡하던데 왜 파폭만 유독 크게 영향을 받았을까요...

ps. 회사에서 서버실 모니터가 급필요하다고 해서 도로 내주고(...) 원래 세팅으로 돌아왔는데 드라이버 업데이트 덕분인지 더이상 그 정도로 심각하게 느려지는 문제는 없군요. +_+