스케일폼 GFx 콘텐츠 우수 사례

개요

언리얼 엔진 3에 통합된 스케일폼 GFx로 사용할 플래시 콘텐츠를 개발할 때 최적의 퍼포먼스를 얻기 위해 잇따라 구현해야 하는 최적화 및 고려 사항이 몇 가지 있습니다. 여기서는 그러한 우수 사례를 선보이겠습니다.

드로 프리미티브

Draw Primitive(드로 프리미티브)란 2D 플래시 요소를 렌더링하기 위해 GFx로 만든 3D 메시 오브젝트로, 같은 레이어에 있는 셰이프의 그룹같은 것을 말합니다. 각 드로 프리미티브는 개별적으로 렌더링되며, 비용이 꽤 발생합니다. 일반적으로 DP(드프)가 화면에 많이 나타날 수록 디스플레이 퍼포먼스는 선형으로 떨어지는 경향을 보이기에, 드프 수를 가급적 줄이는 것이 좋겠습니다. 드프의 수는 [F2] 키를 누르면 나타나는 GFxPlayer HUD를 통해 알아볼 수 있으며, AMP HUD 요약 화면이 뜨게 됩니다. 이 화면에는 트라이앵글 수, 드프, 메모리 사용량 및 기타 최적화 정보가 표시됩니다.

드프 수를 낮추는데 도움이 되는 사실 몇 가지는:

1. gradient fill(그레디언트 필)을 동시에 한 셰이프에다 여러번 사용하면 드프 수가 늘어날 수 있습니다.
2. solid fill(단색 채우기, 솔리드 필) & 같은 레이어에다 stroke(긋기, 스트록)하지 않은 벡터 그래픽은 매우 쌉니다. 단일 레이어 상의 이런 유형의 셰이프를 나타내는 데는, 그 셰이프가 각기 다른 색을 사용할 지라도, 드프는 딱 하나면 됩니다.
3. 자체 레이어상에 있는 벡터 셰이프(나 그 그룹)마다 드프 하나씩 추가요~
4. 모든 스트록이 단색으로 똑같지 않고서야 스트록은 필보다 비쌉니다.
5. 한 레이어의 비-유사 솔리드 스트록(색이 달라질 때)마다 드프 하나씩 추가요~
6. 빈 무비 클립에는 드프가 필요하지 않으나, 오브젝트가 있는 무비 클립은 해당 오브젝트가 지시하는 만큼의 드프 추가요~
7. 알파, 블렌드, 투명 효과는 필요한 드프 수에 영향을 끼치지 않으나, 렌더링 퍼포먼스에는 영향이 있을 것입니다.
8. 스테이지의 비트맵/텍스처마다 드프 하나씩 추가요~
9. 텍스트 필드마다 드프가 최소 하나씩 필요합니다. 경계/배경을 추가하면 드프가 하나 추가됩니다. 대부분의 경우 모든 텍스트 glyph(문양)은 텍스처로부터 드프 하나로 렌더링되나, 큰 텍스트는 각 문양마다 별도의 프리미티브를 사용하는 벡터 셰이프로 렌더링되어 버릴 수가 있습니다. 벡터 문양을 클리핑해야 하는 경우 텍스트 필드는 마스크를 사용하게 되므로 드프 하나 추가요~ 안그래도 지금 마스크는 퍼포먼스상의 비용이 심한 편인데 클리핑된 텍스트 필드가 한 술 더 뜨는 것입니다.

무비 클립

1. 무비 클립을 숨기기 보다는, 사용하지 않을 때는 그냥 시간선에서 완전히 지워 버리는 편이 제일 좋습니다. 안그러면 Advance 도중 처리 시간을 잡아먹게 됩니다.
2. 무비 클립을 지나치게 많이 놓으면 퍼포먼스에 악영향을 끼치니 피하시기 바랍니다.
3. 무비 클립을 꼭 숨겨야 겠으면 _alpha=0 보다는 _visible=false 를 사용하시기 바랍니다. 숨긴 무비 클립에서의 애니메이션은 꼭 "stop()" 함수 호출로 중지해야 합니다. 안그러면 보이지도 않은 애니메이션이 계속 재생되어 퍼포먼스에 악영향을 끼치게 됩니다.

비트맵 대 벡터 그래픽

플래시 콘텐츠는 벡터 아트는 물론 이미지로도 만들 수 있으며, GFx는 벡터와 비트맵 그래픽 둘 다를 매끄럽게 렌더링할 수 있습니다. 그러나 각 유형마다 장단점이 있습니다. 벡터냐 비트맵이냐는 항상 그것이 문제이며, 여러가지 요인에 따라 달라집니다. 여기서는 벡터와 비트맵 그래픽의 차이점에 대해 약간 논하는 것으로 콘텐츠 저작 결정을 돕고자 합니다.

스케일을 조절할 때 벡터 그래픽은 셰이프가 부드럽게 유지되나, 비트맵 이미지는 박스처럼 또는 픽셀화되어 보이게 됩니다. 반면 벡터 그래픽은 비트맵에 비해 생성에 있어 연산력을 더 많이 필요로 하게 됩니다. 간단한 단색 셰이프는 보통 비트맵만큼 빠르기야 하지만, 트라이앵글, 셰이프, 필이 많이 들어간 복잡한 벡터 그래픽은 렌더링하기에 비쌀 수가 있습니다. 결과적으로 벡터 셰이프를 무겁게 사용하면 종종 어플리케이션 퍼포먼스를 떨어뜨릴 수 있다는 것입니다. 경험에 의하면 트라이앵글을 200개 이상 만들어 내는 벡터 셰이프는 그냥 비트맵으로 변환하는 것이 최곱니다.

몇몇 어플용으로는 비트맵 그래픽이 벡터만큼 처리시간이 길지 않아 좋을 수도 있는데, 비트맵 그래픽은 벡터 그래픽에 비해 필요한 메모리의 양이 크게 늘어나게 됩니다.

벡터 그래픽

벡터 그래픽은 다른 이미지 포맷보다 아담한데, 벡터는 비트맵의 그래픽(픽셀) 데이터를 날로 저장하기 보다는 런타임에 이미지를 렌더링하는 데 필요한 계산(포인트, 커브, 필 등)을 정의하기 때문입니다. 그러나 벡터 데이터를 최종 이미지로 변환하는 작업은 시간이 걸릴 뿐 아니라 그래픽의 스케일이나 외형이 크게 변할 때마다 다시 변환해야 합니다. 만약 무비 클립에 프레임마다 변하는 복잡한 셰이프 아웃라인이 있는 경우, 애니메이션은 느리게 돌아갑니다.

다음은 벡터 그래픽을 효과적으로 렌더링하는 데 도움이 될 만한 지침입니다:

• 복잡한 벡터 그래픽을 비트맵으로 변환하고 퍼포먼스에 어떻게 영향을 끼치는지 테스트하여 실험해 봅니다.
• 알파 블렌드를 사용할 때는 염두에 둘 것은:
  • 솔리드-필 스트록은 훨씬 효율적인 알고리듬을 사용하기 때문애 알파-블렌딩 스트록보다 계산하기 좋습니다.
  • 투명 (알파) 사용을 피하십시오. 플래시는 투명한 셰이프 아래의 픽셀도 전부 검사를 해야 하기에 렌더링이 매우 느립니다. 클립을 숨기려면 _alpha 속성을 0으로 하기 보다는 _visible 속성을 false로 설정하시기 바랍니다. _alpha 설정이 100일 때 그래픽 렌더링이 가장 빠릅니다. 무비 클립의 시간선을 빈 키프레임으로 설정하(여 무비 클립에 표시할 콘텐츠가 없게 되)면 훨씬 더 빨라질 수 있습니다. 종종 플래시는 숨긴 클립도 렌더링하려 하는데, 클립의 _x 및 _y 속성을 보이는 스테이지의 위치 밖으로 빼 버리고서 _visible 속성을 false로 설정하면 플래시가 전혀 그리려고 하지 않을 것입니다.
  • 벡터 셰이프를 최적화하십시오.
  • 벡터 그래픽을 사용할 때 가급적 중복점을 없애 셰이프를 단순화하시기 바랍니다. 벡터 셰이프마다 플레이어가 계산해야할 양이 줄어들게 됩니다.
  • 원, 사각, 선과 같은 프리미티브 벡터를 사용하십시오.
  • 플래시의 그리기 퍼포먼스는 프레임당 점이 얼마나 그려지는가에 달려 있습니다. Modify -> Shape 서브메뉴로 가서 (문제되는 그래픽에 따라) Smooth, Straighten, Optimize를 선택하여 그리는 데 드는 점의 수를 줄입니다. GFx 벡터 테셀레이션 코드에 의해 생성되는 메시 데이터를 줄이는 데 도움이 됩니다.
• 코너가 커브보다 쌉니다.
  • 커브와 점이 너무 많은 복잡한 벡터는 피하십시오.
  • 코너 렌더링이 커브보다 수학적으로 간단합니다. 가능하면, 특히나 아주 작은 벡터 셰이프의 경우 엣지를 평평하게 하십시오. 커브를 이런 식으로 흉내낼 수 있습니다.
• 그레디언트 필을 사용하되, 그레디언트 스트록은 넣어두십시오.
• 셰이프 아웃라인(스트록)을 피하십시오.
  • 가능하면 벡터 셰이프에는 스트록을 사용하지 마십시오. 렌더링되는 선의 수가 늘어나기 때문입니다.
  • 벡터 이미지 주변의 아웃라인에는 퍼포먼스 문제가 있습니다.
  • 필에는 바깥쪽 셰이프만 렌더링하면 되는 반면, 아웃라인은 안팎을 다 렌더링해야 합니다. 필에 비해 작업량이 두 배인 셈이죠.
• 플래시의 드로잉 API 사용을 최소화하십시오. 불필요하게 사용하면 퍼포먼스 부하가 심하게 걸릴 수 있습니다. 무비 클립을 한 번 그릴 때는 드로잉 API를 사용해도 좋습니다. 커스텀 무비 클립같은 것을 렌더링할 때는 퍼포먼스 페널티가 없거든요.
• 마스크의 사용을 자제하십시오. 마스크된 픽셀은 계속해서 렌더링 시간을 잡아먹으며, 그려지지 않을 때도 퍼포먼스에 악영향을 끼칩니다. 마스크가 여럿인 경우 사용된 마스크의 수에 따라 충격이 배가됩니다. 아티스트가 마스크를 사용하는 비주얼 이펙트의 대다수는 실제로 마스크를 사용할 필요가 없는 것들입니다. 콕 찝어 보자면, 비트맵에서 셰이프를 오려낼 때 보통 마스크를 씁니다. 플래시 스튜디오에서 셰이프로 직접 비트맵 필을 적용하면 훨씬 효과적으로 똑같은 작업을 해낼 수 있습니다. 또한 스케일폼의 특허출원중인 EdgeAA 앤티-앨리어싱의 덕을 볼 수도 있습니다.
• 가능하면 여러 오브젝트를 하나의 셰이프로 변환하여 부가 드로 프리피티브 생성을 피하십시오.
• 셰이프가 생성된 이후에는 추가 메모리 사용 없이 옮기기, 회전, 혼합 등이 가능합니다. 단지 큰 셰이프를 새로 들여오거나 너무 크게 스케일조절을 해버리면 테셀레이션으로 인해 메모리를 더 쓰게 됩니다.
• EdgeAA가 켜진 상태라면 여러가지 단색으로 구성된 셰이프는 여러가지 그레디언트/비트맵으로 구성된 것보다 빠르게 렌더링됩니다. 한 셰이프 내에서 그레디언트/비트맵을 연결할 때는 드로 프리미티브의 수가 급격히 늘어날 수 있으니 주의하셔야 겠습니다.

비트맵

최적화되고 능률적인 애니메이션이나 그래픽을 만드는 첫 단계는, 만들기 전에 프로젝트의 윤곽을 그리고 계획해 보는 것입니다. 만들려는 애니메이션의 파일 크기, 메모리 사용량, 길이 등에 대한 목표를 설정하고, 개발 과정에서 삼천포로 빠지고 있지는 않은지 수시로 점검해 봐야 합니다.

이미 말한 드로 프리미티브에 추가로, 렌더링 퍼포먼스에 또하나 중요한 요인은 그려지는 총 표면 구역입니다. 보이는 셰이프나 비트맵이 스테이지에 놓일 때마다, 숨겨졌든 다른 셰이프에 겹쳤든 간에 상관없이 렌더링되어야 하는데, 이는 비디오 카드 필-레이트를 잡아먹습니다. 물론 요즘의 비디오 카드는 소프트웨어 플래시 보다는 차원이 다르게 빠릅니다만, 화면상의 커다란 겹치는 알파-블렌딩된 오브젝트는 여전히 퍼포먼스를 크게 저하시킬 수 있으며, 저사양이나 구형 하드웨어에서는 특히나 더할 것입니다. 이런 젼차로 겹치는 셰이프나 비트맵을 고르게해 주는 것이 중요하며, 가려지거나 잘려나간 오브젝트는 확실히 솜겨주는 것이 좋습니다.

오브젝트를 숨길 때는 무비 클립 인스턴스의 _visible 속성을 false로 설정하시는게 최고이며, _alpha 레벨을 0으로 바꾸지는 마시기 바랍니다. GFx는 _alpha 값이 0인 오브젝트를 그리지 않기는 합니다만, 그 자식들의 애니메이션과 액션스크립트에서는 CPU 처리 비용이 계속 발생할 수도 있습니다. 인스턴스 표시여부를 false로 설정하면 CPU 사이클과 메모리가 절약될 가능성이 있으며, 어플의 전체적인 퍼포먼스가 향상되고 SWF 파일의 애니메이션도 부드러워지게 됩니다. 애셋 로딩을 들었다 놨다 하는 대신, _visible 속성을 거짓으로 해 놓으면 프로세서에 훨씬 덜 집중되게 됩니다.

비트맵 그래픽을 효율적으로 렌더링하기 위한 지침 몇을 들어보자면 다음과 같습니다:

• 텍스처/비트맵을 만들 때는 폭과 높이가 2승수가 되도록 하십시오. 예를 들면 16x32, 256x128, 1024x1024, 512x32 같은 비트맵 크기가 좋습니다.
• 이미지에 JPEG 압축을 사용하지 마십시오. 파일 로드 도중 압축 해제 시간이 필요해 집니다.
• 텍스처 압축을 통한 비트맵 메모리 요구치를 줄이려면 gfxexport 툴을 사용하여 최종 SWF를 GFX 포맷으로 변환할 때 DDS 텍스처 압축 스위치를 켜고 하시기 바랍니다. 압축된 텍스처의 비트맵 메모리는 미압축 텍스처와 비교했을 때 4배 정도 차이가 납니다. DDS 포맷은 손실 압축이니 결과 비트맵의 품질이 괜찮은지 확인하시기 바랍니다. gfxexport의 옵션 -qp 또는 -qh를 사용하면 최고 품질의 DDS 텍스처를 얻을 수 있습니다. (단 비트맵 이미지 처리 시간이 오래 걸릴 수 있습니다.)
• 비트맵을 적게 그리고/또는 치수가 작은 비트맵을 사용하십시오.
• 크고 단순한 셰이프를 표현하는 데 비트맵이 사용된 경우, 벡터 그래픽을 사용하여 비트맵을 재생성하십시오. EdgeAA로 품질도 낫고 메모리도 절약될 것입니다.
• 필요한 경우 액션스크립트를 통해 큰 비트맵의 로딩 및 언로딩을 고려해 보십시오.
• SWF/GFX 파일의 크기는 그 메모리 사용량과 일치하지 않습니다. SWF나 JPG 파일 크기가 작을 수는 있어도, 불러와서 압축을 풀고 나면 메모리를 많이 차지할 수 있습니다. 예를 들어 SWF 파일에 끼워넣은 1024 x 1024 JPEG 이미지가 있는 경우, 파일 크기는 작을지 모르겠지만 런타임에 이미지에 대한 용량은 (텍스처 압축이 없다고 가정한다면) 4MB 정도 될 것입니다.
• UI에 사용되고 있는 이미지 파일의 크기와 수를 추적하는 것이 중요합니다. 이미지 크기를 전부 헤아려서 더한 다음 4로 (보통 픽셀당 4바이트이니) 곱해줍니다. gfxexport 툴에 -i DDS 옵션을 사용해 줘야 텍스처 압축을 사용하여 이미지 메모리 사용량이 4배 줄어든 다는 점 기억해 주십시오. 비트맵의 메모리 소비를 측정하려면 AMP를 사용하십시오.
• 전체적으로, 대부분 복잡한 셰이프의 경우 비트맵은 빠르지만, 벡터는 품질이 좋습니다. 시스템의 필 레이트, 변형 셰이더 퍼포먼스, CPU 속도에 정확히 따르는 상충 관계에 있는 것입니다. 결국 제대로 알아낼 수 있는 딱 한가지 방법은 대상 시스템에서 퍼포먼스를 직접 확인해 보는 길 뿐입니다.
• 그레디언트 텍스처만을 포함하는 마스터 gradient.swf 파일을 만들어서 필요에 의한 다른 SWF 파일 속으로 가져오십시오. gfxexport 툴에서 -d0 스위치를 사용하여 gradients.swf를 내보냅니다. 압축을 끄는 스위치로, 해당 SWF 파일에 있는 모든 텍스처에 적용되게 됩니다. 이 파일에서 그레디언트를 사용하는 모든 텍스처에는 밴딩(banding)이 없게 됩니다.
• 가급적 알파 채널이 있는 비트맵은 피하십시오.
• 플래시가 아닌 어도비 포토샵®같은 이미지 처리 어플로 비트맵을 최적화하십시오.
• 비트맵 투명도가 필요한 경우 PNG를 사용하시고 그려지는 총 표면적을 줄여 보시기 바랍니다.
• 큰 비트맵을 겹치면 필-레이트 퍼포먼스에 악영향을 끼치니 피하시기 바랍니다.
• 비트맵 그래픽은 어플에서 사용될 크기로 가져오십시오. 큰 그래픽을 가져온 다음 플래시에서 스케일을 낮추면 파일 크기와 런타임 메모리가 낭비됩니다.

애니메이션

어플에 애니메이션을 추가할 때, FLA 파일의 프레임율을 고려하십시오. 최종 SWF 파일의 퍼포먼스에 영향을 끼칠 수 있습니다. 프레임율을 너무 높게 잡으면 퍼포먼스 문제가 생길 수 있으며, 많은 애셋이 사용되거나 그대로가 다큐먼트의 프레임율에 틱되는 애니메이션을 만드는 데 사용된 경우는 특히나 더합니다.

그러나 프레임율 세팅은 애니메이션이 얼마나 부드럽게 재생되는가에도 영향을 끼칩니다. 예를 들어 초당 12 프레임(FPS)으로 설정된 애니메이션은 매 초마다 시간선의 12프레임을 재생합니다. 만약 다큐먼트의 프레임율을 24 FPS로 설정한다면, 애니메이션은 12 FPS로 설정했을 때보다 좀 더 부드럽게 나올 것입니다. 반면 24 FPS의 애니메이션은 12 FPS의 것보다 두 배로 빨리 재생하는 셈이기에, 총 재생 기간은 (초로 따질 때) 절반이 될 것입니다. 고로 5초짜리 애니메이션의 프레임율을 높여 만들려면 낮은 프레임율의 것보다 5초만큼을 부가적으로 채워 넣어야 하기에, 총 파일 크기가 커지게 됩니다.

주: 스크립팅된 애니메이션을 만들기 위해 onEnterFrame 이벤트 처리기를 사용하면, 애니메이션은 시간선상에 모션 트윈을 만들 때와 비슷하게 다큐먼트의 프레임율로 돌아갑니다. onEnterFrame 이벤트 처리기에 대한 대안은 setInterval 입니다. 프레임율에 의존하는 대신 밀리초로 지정된 기간마다 함수를 호출합니다. onEnterFrame처럼 setInterval이 함수를 자주 호출하게 할 수록 애니메이션의 리소스 의존도 또한 커지게 됩니다.

가급적 런타임에 애니메이션이 부드럽게 나오는 수준에서 최저 프레임율을 사용하십시오. 프로세서의 퍼포먼스 문제를 줄이는 데 도움이 됩니다. 30에서 40 FPS 이상의 프레임율은 가급적 사용하지 마십시오. 이보다 높은 프레임율 지름신은 단지 CPU 비용만을 잉태하실 뿐이옵고, 애니메이션 품질도 크게 하사하시지 않으실 것입니다. 대부분의 경우 플래시 UI의 프레임율은 게임의 목표 프레임율 절반 정도로만 설정해 줘도 안전합니다.

다음은 효율적인 애니메이션 제작 및 디자인에 도움이 되는 지침 몇 가지입니다:

• 스테이지상의 오브젝트 수와 물건이 움직이는 속도가 전체 퍼포먼스에 영향을 끼칩니다.
• 스테이지상에 무비 클립이 많이 있는 데다 빠르게 껐다/켰다 해야 하는 경우, 무비 클립의 첨부/제거 보다는 _visible = true/false 옵션으로 표시여부를 제어하는 것이 좋습니다.
• 트윈 사용시 세심한 주의를 기울이십시오.
  • 너무 많은 아이템을 동시에 트윈하지 마십시오. 하나가 끝나면 다른게 시작될 수 있도록 트윈 및/또는 시퀸스 애니메이션 수를 줄이십시오.
  • 가능하면 표준 Flash Tween 클래스 대신 시간선 모션 트윈을 사용하십시오. 퍼포먼스 부하가 훨씬 적게 걸립니다.
  • 스케일폼에서는 표준 Flash Tween 클래스보다 작고 빠르고 깨끗한 CLIK Tween 클래스 (gfx.motion.Tween) 사용을 권하고 있습니다.
• 프레임율이 높건 낮건간에 알아채기가 쉽지 않으니, 프레임율은 낮게 유지하십시오. 프레임율이 높을 수록 애니메이션도 부드러워 지기는 하지만, 퍼포먼스 악영향도 늡니다. 초당 60 프레임으로 돌아가는 게임에서 플래시 파일도 60 FPS로 맞출 필요는 없습니다. 플래시 프레임율은 적절한 시각 효과를 내는 데 필수적인 최소 프레임율이면 됩니다.
• 투명도와 그레디언트는 프로세서 의존도가 심한 작업이니 아껴 써야 합니다.
• 포커스 구역을 잘 디자인하여 애니메이팅되게 만들고, 화면의 나머지 구역에는 애니메이션과 효과를 줄이십시오.
• 이행 도중에는 (미묘한 배경 효과같은) 수동 배경 애니메이션을 일시정지하십시오.
• 애니메이팅되는 엘리먼트를 추가/제거해 가며 퍼포먼스상의 영향을 재 보십시오.
• 트윈 완화는 잘 써야 합니다. 느린 하드웨어에서는 "랙같아" 보일 수 있습니다.
• 원을 사각형으로 변태시키는 등의 셰이프 모핑 애니메이션은 매우 CPU 의존도가 높은 작업이니 피하십시오. 셰이프는 매 프레임마다 계산되기에 셰이프 트윈(모핑)은 CPU 부하가 매우 심각한 녀석입니다. 그 부하량은 셰이프의 복잡도(엣지, 커브, 교차 등의 수)에 따라 달라집니다. 특정 시나리오에서는 쓸만할 수도 있지만, 감당할 만한 비용인지 프로파일링하여 검증해 보십시오. 4-트라이앵글 트윈 비용 정도는 괜찮을 것입니다. 근본적으로 주의해야 하는 퍼포먼스/메모리 상충 관계가 있습니다. 정규 셰이프를 표시할 때는 나중의 프레임에도 효율적으로 표시하기 위해 테셀레이션과 셰이프의 캐시가 수단되게 됩니다. 모프가 일어나게 되면 셰이프가 바뀌게 되고, 이는 곧 에전 메시를 버리고 새로운 것을 만들어야 하게 되니 상충 관계가 바뀌는 것입니다.
• 가장 효율적인 애니메이션은 옮기기와 회전입니다. 애니메이션 스케일 조절은, (느껴질만한 퍼포먼스 저하가 있을 수 있는) 재-테셀레이션을 유발하고 그 결과 메시가 메모리를 더 차지할 수도 있기에, 피하는 게 최상책입니다.

텍스트와 폰트

• 텍스트 문양 폰트 사이즈는 폰트 캐시 매니저 SlotHeight 또는 gfxexport에 사용하려고 계획한 (기본값은 48 픽셀) 값보다 작아야 합니다. 큰 폰트가 사용되는 경우 벡터가 사용되게 되며, 결과적으로 (각 벡터 문양마다 드프가 추가되니) 드프 수가 많아져서 훨씬 느려지게 됩니다.
• 가능하면 텍스트 필드의 경계와 배경을 끄면 드프 하나 주문 취소요~
• 매 프레임마다의 텍스트 필드 내 콘텐츠를 업데이트하는 것은 퍼포먼스 저하의 주범 중 하나이나 쉽게 피할 수 있습니다. 콘텐츠가 정말로 바뀌었을 때만, 아니면 가급적 제일 느린 속도로 텍스트 필드 값을 바꿔주면 됩니다. 예를 들어 초를 표시하는 타이머를 업데이트할 때는 30 FPS 속도로 업데이트할 필요가 없습니다. 그냥 예전 값을 기록해 뒀다가 새로운 값이 예전 값과 다를 때만 텍스트 필드의 값을 재지정해 주면 됩니다.
• 텍스트 필드에 링크된 변수("TextField.variable" 속성)를 사용하지 마십시오. 텍스트 필드가 변수의 값을 매 프레임마다 가져와서 비교를 하게 되어 퍼포먼스에 악영향을 끼칩니다.
• "htmlText" 속성 재할당을 통한 텍스트 업데이트를 최소화하십시오. HTML 파싱은 비교적 비싼 프로세스입니다.
• 문양 모양(, 특히 아시아 폰트를 끼워넣은(embed) 경우)에 드는 메모리를 절약하기 위한 폰트 압축에는 gfxexport에다 -fc, -fcl, -fcm 옵션을 사용하십시오. 자세한 것은 "폰트 개요" 문서를 참고하십시오.
• 현지화가 필요한 경우 폰트용으로 필수인 심볼만 끼워넣거나 fontlib 메카니즘을 사용하십시오. (마찬가지로 "폰드 개요" 문서 참고.)
• TextField 오브젝트는 가급적 복수의 아이템을 하나로 합쳐서 필요한 수 만큼만 사용하십시오. 텍스트 필드 하나는 색이나 폰트 스타일이 달라져도 보통 드프 하나로 렌더링 가능합니다.
• 텍스트 필드의 스케일 조절이나 큰 폰트 사용을 피하십시오. 텍스트 필드가 일정 크기를 넘어가면 벡터 문양으로 전환되며, 각 벡터 문양은 드로 프리미티브가 됩니다. (벡터 문양의 일부만 보이는) 클리핑이 필요한 경우엔 마스크가 사용됩니다. 마스크는 느린데다 드프 하나 서비스요~ 래스터화된 문양의 클리핑에는 마스크가 필요치 않습니다.
• 문양 캐시 크기가 사용된 문양 전체(나 대부분)를 담을 만큼 충분한지 확인하십시오. 캐시 크기가 충분하지 않으면 일부 문양은 사라지거나, 문양의 재-래스터화 빈도가 높아져 퍼포먼스상에 심각한 문제가 생기게 됩니다.
• 블러, 그림자, 넉아웃 필터 등의 텍스트 효과를 사용하면 폰트 캐시에 필요한 공간이 늘어나게 되며, 퍼포먼스에도 영향을 끼칩니다. 가급적 텍스트 필터의 사용을 최소화하십시오.
• 텍스트 필드 밑줄에도 드프 하나 추가되니 자제하십시오.