jasu's blog

플래시는 화면에 올려진 모든 오브젝트를 FPS에 따라 화면에 다시 그리는 과정에서 연산처리에 영향을 주어 CPU 속도를 떨어뜨리게 되는데, 비트맵을 활용하면 사용자의 인터렉션에 영향을 주지 않는 범위를 하나의 오브젝트로 대체하여 속도를 개선할 수 있다.

[아래 보여지는 결과물은 화면이 작은 관계로 오른쪽에 버튼이 개수가 많지 않기 때문에 효과를 제대로 확인하기 위해서는 왼쪽 상단에 있는 ‘F’ 버튼을 눌러 전체 화면으로 하고 테스트해야 한다.]

위 결과물은 왼쪽에 메뉴에 해당하는 버튼그룹이 있고 오른쪽에는 마우스를 오버하면 scale을 주기적으로 변경하는 모션이 적용되어 있다. 왼쪽 메뉴에 해당하는 수많은 버튼들이 모두 stage 상에 올려져 있을 경우, 플래시 전체에 영향을 주어 모션이 부자연스럽고 느리게 움직이는 것을 볼 수 있다.

이때 오른쪽 상단의 ‘비트맵 변환’ 체크박스를 체크하고 확인해 보면 모션이 자연스럽게 적용되는 것을 볼 수 있다. 비트맵 변환을 체크할 경우 왼쪽에 있는 모든 버튼들은 하나의 비트맵으로 처리하여 시각적으로 존재하는 버튼처럼 적용된 것이다. 이렇게 하나의 비트맵으로 적용하여 화면에 배치할 경우 버튼에 마우스 오버시 색을 표시하는 오버효과가 적용되지 않는다. 그렇기 때문에 사용자가 왼쪽 메뉴 영역으로 마우스를 이동할 경우 기존의 비트맵 이미지를 다시 원래의 버튼들로 대체하여 사용자의 눈을 속이는 것이다.

사용자가 마우스를 이동할 경우 인터렉션 반응을 하지 않아도 되는 영역을 이렇게 하나의 오브젝트로 대체하는 것만으로도 플래시의 불필요한 속도저하 요소를 제거할 수 있다.

작업한 파일을 주말 동안 브라우저에 올려 놓고 몇 시간을 놔두었더니 CPU 점유율이 서서히 올라간다. 어디서 문제가 있는지 고민해 보았는데 이상하게도 메모리에는 이상이 없는 것 같은데 유독 CPU 점유율만 서서히 상승하는 것이다. 그래서 몇 개의 클래스를 두고 하나 하나 테스트를 해봤는데 결국 예전에 만들었던 DZeroNumber.as 클래스에서 문제가 있는 것으로 나타났다.

그런데 그 클래스 내에서도 특별히 문제가 될만한 곳을 발견하지 못하였는데 결국 생각지도 못한 곳에서 문제가 발생하고 있었다. DZeroNumber 클래스에서는 지정한 텍스트 필드에 00000 부터 지정한 숫자만큼 다이나믹하게 넘버링 하는 기능을 하고 있는데 그 클래스에서 000에 해당하는 부분과 실제 숫자에 해당하는 부분의 색을 달리하기 위해 TextField.htmlText 속성에 html 태그를 포함한 String을 넣고 있었다. 그런데 이 htmlText 속성이 문제가 있다.

TextField.text = "String" 을 넣을 때에는 CPU 점유율이 고정이지만 하나의 TextField에 htmlText속성을 통해서 html 태그를 포함한 String을 주기적으로 넣었을 때는 html 태그를 렌더링하는 과정에서 CPU 점유율이 점차적으로 상승한다. 그리고 이 상승하는 CPU 점유율은 swf파일이 종료되지 않는 이상 떨어지지 않는다.

TextField.htmlText = "<b> text </b>"

위와 같은 형태로 html 태그를 계속해서 TextField.htmlText에 넣게 되면 점차적으로 CPU 점유율이 100%를 향해 달려가니 주의가 필요하다.

플래시를 전문적으로 하지 않는 기획자나 다른 개발자의 경우에는 플래시의 CPU문제(버벅거림)에 대해서 막연하게 생각하는 경우가 많다. 플래시의 CPU 사용에 대한 문제는 항상 국내의 화려한 비주얼의 걸림돌이 되곤 한다.

플래시의 CPU 문제는 단적으로 말하면 flashplayer가 한번에 처리해야 하는 계산이 많다는 것을 의미한다. 예를 들면 아래와 같은 경우다.

비주얼 문제
* 복잡한 라운드 처리가 되어 있는 백터 이미지
* 그라데이션이 적용된 백터 이미지
* 알파가 적용된 DisplayObject
* 프레임이 진행하고 있는 MovieClip의 다수 복제
* 큰 사이즈의 이미지(백터 and 비트맵)
* 플래시에서 필터를 적용한 오브젝트의 움직임
...

액션스크립트 문제
* Array의 length
* .연산자
* ["instance name string"] 참조
...

이 밖에도 많은 경우의 수에 의해서 플래시 내에서 처리되는 속도는 차이가 날 수 밖에 없다. 아무리 좋은 디자인으로 표현이 되었더라도 동적인 움직임으로 표현을 해야 하는 플래시 개발자들은 이러한 문제를 항상 안고 작업을 한다.

플래시가 버전업을 하며 날로 발전을 하고 있음에도 그 발전에 대해 충분히 활용하지 못하는 경우가 많은 것 같다. 예를 들면 플래시8 버전부터 추가된 BitmapData, Bitmap 클래스는 ActionScript로 비주얼적인 표현을 할 수 있지만 위에서 이야기한 플래시의 CPU문제를 어느 정도 해결할 수 있는 방법이기도 하다.

플래시 스테이지상에 있는 모든 오브젝트들은 플래시플레이어가 계산해야 하는 영역 안에 있기 때문에 언제든지 CPU의 과부화를 만들어 낼 소지가 있다. 따라서 보여지는 화면 내에 걸쳐있는 모든 오브젝트들의 묘화에 필요한 계산을 줄이기 위해서 BitmapData 클래스를 사용할 수 있다. 

특정 DisplayObject 안에 있는 수많은 오브젝트들을 하나의 DisplayObject로 변환하고 다시 되돌리는 클래스를 만들어 특정 DisplayObject를 하나의 DisplayObject로 변환했다가 그 안에 있는 개별적인 요소의 기능을 사용해야 할 경우에는 원래의 DisplayObject로 변환하여 사용하지 않을때 낭비되는 CPU 문제를 해결할 수 있다.

블로그의 INFINITE의 왼쪽 메뉴의 경우도 위와 같은 방법을 사용한 예다. 마우스를 오버했을 때 메뉴가 나타나고 원래의 오브젝트로 되돌려 버튼을 사용하도록 하고 다시 메뉴 영역에서 마우스를 아웃 했을 때는 하나의 MovieClip으로 대체하여 불필요한 요소를 제거했다.

플래시의 CPU문제와 용량의 문제는 항상 비례하는 것이 아니다. 그리고 파일 용량과 RAM용량 또한  그러하다. 가끔 기획자나 디자이너들이 플래시의 CPU문제 == 파일용량크기 와 결부시키는 경우를 종종 보게 된다.

INFINITE의 메뉴 같은 경우를 보면 원래의 DisplayObject를 되돌려야 하기 때문에 메모리 영역에서 삭제해서는 안 된다. 이 때문에 RAM용량을 줄이는 방법이 아니며 이는 오로지 화면상에 표시되는 오브젝트들로 인해서 flashplayer에 의한 CPU 낭비를 줄이기 위한 방법인 것이다.

요즘은 플래시 개발자와 디자이너가 전문성을 위해서 분업화 되어 있지만 그로 인해서 디자이너들이 플래시에 대한 이해가 부족하여 생기는 문제도 다분히 존재하는 것 같다. 개인적인 생각이지만 국내 웹에이전시에서는 각 분야의 전문성도 중요하지만 작업자 간의 커뮤니케이션에 필요한 기본적인 타 업무에 대한 이해와 교육이 필요한 시기가 아닌가 싶다.