Re: HTML5 game app 개발시 이슈들...

On Thursday, October 10, 2013 at 11:54 AM, Chang W. Doh wrote:

[…]  
> > > - devicePixelRatio가 1.5일 경우 canvas로 rendering 시 화면을 깨끗하게 그리는 것이 쉽지 않음
> >  
> > 이 부분은 왜 그런지 궁금하네요^^; 혹시 안드로이드와 iOS 모두 같은 현상이 발생하나요?
>  
> 브라우저 입장에서는 캔버스 역시 렌더링 트리에 존재하는 노드 중의 하나일 뿐이라 어느 정도의 Jaggies가 발생하지 않을까 싶은데요.
> 디스플레이의 배율을 정수로 떨어지는 값으로 맞추기에는 게임 스크린 자체의 해상도 저하로 인한 품질 이슈도 있을 것이구요.

배수 특성상 interpolation이 발생할 수 밖에 없고, 코드 자체가 FPU 연산을 해야하는지라 때문에 정수 배수 scaling에 비해서 느릴 수 밖에 없습니다. 아무리 VFPv3/4나 NEON으로 floating point 연산을 할 수 있다고 해도 FPU를 사용하게 되면 당연히 범용 레지스터에서 적당히 비빌 수 있는 정수 연산에 비해서는 느릴 수 밖에 없습니다.

행여나 부동소수점 연산이 느린 단말의 (예로 구형 Tegra 칩셋을 채택한..) 경우라면 이 문제는 더더욱 심각해집니다.
> > > 3) Garbage collector 문제
> > > - 게임 반응성 저하: static object등을 써서 일부 완화/회피 가능하다지만, 그렇게 짜는 것들이 쉽지 않음
> >  
> > 이 부분은 브라우저에게 지속적으로 개선해 가고 있는 부분인데 시간이 좀 걸릴 것으로 예상이 됩니다.
>  
> 거의 모든 곳에서 object pool을 이용한 GC 회피 방안을 제시하고 있는데 저도 동일한 의견입니다. 모듈화된 개발과 대치되는 부분도 있구요.

JSC나 V8에서 OOM 시나리오 처리 방식이나 GC 스케쥴링에 대해서 잘 알지는 못합니다만, 만약에 OOM 직전에 rainy day buffer까지 침범, 또는 침범 직전의 시나리오라면 대부분의 JIT엔진이든 intepreter 엔진이든 메모리 확보를 위해 단순히 GC뿐만 아니라 GC가 끝난 시점에서 조각화된 메모리를 정리를 하게 되는데, 이게 꽤나 시간이 걸립니다. GC 방법론 자체의 최적화는 있을 수 있다고 생각합니다만 (예를 들자면 제일 무식한, naive mark/sweep 알고리즘을 채택하였다면 좀 더 똑똑한 방식으로 처리한다든가) 메모리 재배열 자체는 왕도가 별로 없습니다. 이동시킬 때 first fit으로 접근을 하느냐 아니면 best fit으로 접근을 하느냐의 차이라고 생각됩니다만, 각각 장단점이 있는지라… 특히나 메모리 제약이 심한 경우에는 first fit으로 할 경우에 머지 않은 미래에 또 다시 GC를 해야하는 문제가 발생을 하게 되는데, 아무튼 복잡한 문제입니다.

공교롭게도 현재 상황에서는 정말 GC가 문제가 되고, 타이밍이 매우 중요한 코드를 제공해야하는 상황이라면 dynamic language를 사용하지 않으셔야 합니다. 브라우저가 아무리 멀티프로세스/멀티스레드가 된다고 해도 GC를 할 동안에는 ecmascript runtime을 일시 정지시켜야 하고 그러는 만큼 타이밍 오차가 발생할 수 밖에 없습니다.
> >  
> > > 4) CSS 3D를 rendering back-end로 사용 하는 경우
> > > - object 개수 늘어나면 성능의 급격한 저하, iOS도 100개 넘어가면 성능 저하 심함
> >  
>  

Exynos4/Mali400 에서 Blink엔진을 갖고 이런저런 테스트/실험/프로파일링을 해본 결과 대부분의 경우 GPU 단에 메모리가 부족하거나 그쪽에 GLES 콜을 했을때 반응이 점점 느려지는걸 확인했습니다. 애석하게도 드라이버 소스 코드는 SoC/BSP 파트너가 아니면 제공이 되지 않기 때문에 이게 드라이버 버그인지는 확인하지 못했습니다만, 브라우저단에서 할 수 있는건 제한이 좀 있다고 봅니다.

PowerVR SGX의 경우 화질을 희생시키면서 텍스쳐 압축 같은 꼼수가 있긴 한데 애석하게도 최종 확인을 했을때 (작년입니다만) 아직 target에서 할 수 있는 방법은 없었던걸로 기억됩니다. (PC에서 PowerVR 툴을 갖고 압축을 미리 해야 했던걸로 기억됩니다.) Imagination에서 압축 텍스쳐를 쓸 경우에 속도 향상을 기대할 수 있다고 들었습니다만, 현실적으로 브라우저에서 쓸 수 있는 방법이 없으니 그것도 문제입니다. (여담으로 - 내부를 뜯어보지는 않았습니다만, 제 추정에는 Nintendo Wii U Browser의 경우에 lossy [압축? resampled?] 텍스쳐를 사용하는 것 같습니다. 한번 테스트를 해보시면 알겠지만 텍스쳐들이 선명하지가 않고, 12pt 미만의 폰트가 그냥 뭉개져 나옵니다. PVR의 압축 텍스쳐가 설령 target에서 지원이 된다 하더라도 이런 문제가 있습니다.)

아울러 Adreno 같은 복병들이 간혹 있는데, 좋은 이야기는 안나올것 같아서 이 내용에 대해서는 자세히 설명은 안하겠습니다.

아울러 웹 브라우저 특성상 겉보기에는 raster이지만 실제로는 vector하고 유사하기 때문에 생각하는것 보다 텍스쳐 메모리를 크게 잡아야하는 문제도 있습니다. 부정적인 이야기만 한 것 같은데, 현실이 그렇습니다. :(

문상환 배상

Received on Thursday, 10 October 2013 16:07:20 UTC