2013년 12월 30일 월요일

[튜토리얼/한글화] CSS 페인트 타임과 페이지 렌더 가중치 (CSS Paint Times and Page Render Weight)

HTML5Rocks 'CSS 페인트 타임과 페이지 렌더 가중치(CSS Paint Times and Page Render Weight By +Colt McAnlis)' 한글 튜토리얼이 업데이트되었습니다.

이전에 포스팅한 렌더링 관련 튜토리얼들은 웹킷 혹은 크롬의 렌더링 모델이 취하는 구조나 그로 인한 렌더링 성능의 형태 및 최적화에 대해 논의한 글이었습니다. 그리고 이 튜토리얼은 조금 다른 관점에서의 렌더링 성능과 관련하여 가중치와 그 측정 방법에 대해 논의하고 있습니다. 특히, CSS의 속성들의 조합이 그 각각의 페인트 시간의 합보다 더 많은-심지어 훨씬 더 많은- 시간을 소모할 수 있다는 것은 특별히 더 염두에 두어야 할 내용 중의 하나입니다. :)

"GPU 기반으로 가속되는 그래픽스의 성능 향상은 웹에서도 많은 효과를 가능하도록 만들었습니다. 그러나 그래픽스 시스템이 가지는 특성으로 인해 이러한 효과들이 조합되는 경우 중 어떠한 것들은 우리가 기대하는 바와는 달리 더 많은 렌더링 시간을 차지하여 예상치 못한 성능 상의 영향을 주기도 합니다."



TL;DR;


크롬에서의 하드웨어 가속 경로는 페이지를 페이지의 시각적요소를 레스터화하여 타일들로 출력(Paint)하며 이를 합성(Compositing)을 통해 최종적으로 출력합니다. 그리고 CSS에 의한 렌더링 모듈은 각각이 다른 동작을 수행합니다. 그렇다면 그러한 다른 CSS 속성이 여러분의 페이지를 렌더링하는 비용에 어떤 영향을 줄까요?


  • 일반적으로 더 비싼 렌더링 비용이 드는 CSS 속성들이 있습니다. 예를 들어 opacity는 빠르게 처리되지만 그라데이션이나 그림자는 그렇지 않습니다.
  • CSS 속성의 조합은 그들 부분의 합보다 훨씬 더 많은 페인트 시간을 가질 수 있습니다. 즉, A와 B에 해당하는 2가지의 CSS가 하나의 엘리먼트에서 결합될 때 예상과는 다르게 A + B보다 렌더링의 시간이 더 걸린다는 것입니다.


정확하게 판별하자면 CSS의 속성뿐만이 아니라 그 값과 그에 이어지는 다른 속성과의 조합에 따라 성능은 달리 나타날 수 있습니다. (어떤 CSS 속성들이 비용을 발생하는지는 크롬 개발자도구의 Continuous Paint mode를 사용하여 알 수 있습니다.) 이 튜토리얼은 이러한 성능을 어떻게 평가할 수 있는지에 대한 기초적인 이해에 도움될 것입니다.


번역 링크

[튜토리얼/한글화] 객체 풀 기반의 정적 메모리 자바스크립트(Static Memory Javascript with Object Pools)

HTML5Rocks '객체 풀 기반의 정적 메모리 자바스크립트(Static Memory Javascript with Object Pools By +Colt McAnlis)' 한글 튜토리얼이 업데이트되었습니다.

아시다시피 자바스크립트에서는 자바와 마찬가지로 개발자가 직접 메모리를 관리할 필요가 없습니다. 이 둘은 전혀 다른 언어 스펙을 가지고 있지만 메모리 관리에 대해서는 가비지 콜렉션(Garbage Collection, 이하 GC)을 사용하기 때문입니다. 이번 튜토리얼은 이러한 GC의 동작을 회피하기 위해 정적으로 메모리 공간을 할당하고 이를 지속적으로 재사용하는 모델을 자바스크립트를 기반으로 설명합니다.

이번 번역은 김훈민님께서 수고해주셨습니다.  :)

"GC는 개발자가 메모리를 직접 관리하는 대신 경험적으로 효율적이라 판단되는 형태로 메모리를 자동으로 수거하고 관리합니다. 그러나 메모리의 할당/해제는 아주 오래된 성능 병목지점의 하나이기 때문에 직접적으로 관리하지 못하는 모델에서는 순간적인 지연으로 인한 멈칫거리는 현상이 발생하고는 합니다. 정적 메모리 모델은 모든 것에 대한 해답은 되지 못하지만 GC가 유일한 메모리 관리 모델인 이러한 경우들에서는 유일한 해결 방법이기도 합니다."



TL;DR;


가비지 콜렉터는 자동 메모리 관리의 한 형태입니다. 가비지 콜렉터는 가비지, 또는 프로그램이 사용하다가 더이상 필요가 없어진 객체가 점유하고 있는 메모리를 수거합니다. 그러나 메모리를 수거하는 과정은 비용이 들어감으로 인해 일정 시간이 지나면서 웹 게임/웹앱의 성능이 심하게 저하되는 이유 중의 하나는 가비지 콜렉션(Garbage collection) 실행으로 인한 것이라 할 수 있습니다. 이에 대한 해결 방법은 "메모리 변동(memory churn)"이라 불리는 지나친 객체 생성/제거를 가능한 막는 것이며 이것이 GC 동작을 줄이는 방법의 핵심입니다.

정적 메모리 JavaScript는 애플리케이션의 시작 시점에 실행하는 동안에 필요한 모든 메모리를 사전할당(pre-allocating)하고 객체가 더 이상 필요없어지면 실행 중에 메모리를 관리하는 테크닉입니다. 이 방법은 객체를 가비지 콜렉팅이 대상가 되지 않도록 유지하므로 GC가 성능에 미치는 영향을 줄일 수 있습니다. 함께 사용할 수 있는 추가적인 방법으로 객체 사전할당(Pre-allocating objects)을 통해 실행중에 동적으로 발생하는 객체 할당의 양을 줄일 수 있습니다.

그러나 객체 풀 자체가 GC가 발생하는 조건에 좀 더 가까워지도록 만들기 때문에 모든 애플리케이션에 적용할 수는 없으며 주의해서 사용해야 하는 테크닉이기도 합니다.

번역 링크

참고 글

2013년 12월 29일 일요일

[업데이트] Yeoman 월간 다이제스트 #2 (The Yeoman Monthly Digest #2)

+Addy Osmani가 'Yeoman 월간 다이제스트 #2'를 포스팅했습니다. 더불어서 +Jimmy Moon 님이 이번에 +Yeoman 코어팀 멤버가 되셨네요. 축하합니다! 기념해서 이번 요약 설명은 +Jimmy Moon님의 포스팅으로 대신합니다. :)

"+Yeoman 월간 다이제스트 2호가 발간 되었습니다. 이번호 에서는 grunt pro-tips 을 포함해서 역시 Yeoman 을 활용하는 다양한 Video, Tutorial 이 있습니다. MadJs, NetbraskaJS Meetup 의 강좌 비디오가 있구요 AngularJs, Ember.Js 그리고 Node.js 를 활용한 강좌와 Cordova 를 이용해서 만드는 Webapp 강좌가 있습니다. 
yo 는 1.0.7-pre 가 npm 에 올라와 있구요. Backbone, AngularJs, Ember.JS, WebApp, Polymer 그리고 Chrome App Generator 공식 제네레이터들이 버전업 되었습니다. 그외로 프레젠테이션으로 유명한 Reveal.js, Javascript 3D Library three.js 등의 커뮤니티 제네레이터들을 선정했습니다."

월간 다이제스트의 전문은 아래를 참고하시기 바랍니다.


Yeoman

Yeoman 월간 다이제스트 #2 전문


안녕, 안녕? 행복한 연휴되시길! 여러분이 좋아하시는 모자 쓴 남자와 함께 무엇이 새로워졌는지를 훤히 알 수 있는 우리의 공식적인 글들, 팁들, 생성기들 그리고 비디오들을 담고 있는 Yeoman의 월간 다이제스트의 2번째 이슈에 오신것을 환영합니다. 아래의 소식에서 도움되는 것을 찾을 수 있기를 바랍니다!


프로페셔널한 Grunt 조언들(Pro Tips)


존재하는 모든 Grunt 플러그인을 시도해는 것은 구미가 당기는 일입니다. 엄청 많고 많죠!! 게다가 흥분하기도 쉽습니다. 이를 깨닫기까지 여러분은 실제 사용보다 더 오랜 시간동안 터미널을 노려보고 있어야 할 것입니다. 이는 빌드를 하는 동안에도 좌절하는 일이지만 실제 터미널을 지켜보는 동안에도 훨씬 더 많이 좌절하게 만들 것입니다.

다행히도 커뮤니티는 개발 사이클은 한층 더 빠르게 만드데 노력을 기울여 왔습니다.
  • 커스텀 작업 트릭을 이용한 Grunt 의 컴파일 시간의 감소
  • 변경된 파일들에 대해서만 Grunt 작업을 실행하기 위한 grunt-newer의 사용
  • 작업을 병렬로 수행하는 grunt-concurrent을 실행하여 여러 작업들을 동시에 실행할 수 있도록 함
그외의 조언들은 다음과 같습니다.




생성기


yo 1.0.7-pre 버전은 현재 NPM에서 테스트 가능하며 차주 중에 2014년 로드맵에 대해 더논의할 것이 없는지 확인할 것입니다. 그 사이에 공식 생성기와 여러분들이 작성했던 것에 대한 새로운 업데이트들이 아래와 같이 흘러넘칠 지경입니다.


공식 생성기에 대한 업데이트


  • Backbone 0.2.2 버전 릴리즈
    • RequireJS와 CoffeeScript 지원
    • --appPath 옵션 지원
  • AngularJS 0.7.1 버전 릴리즈
    • Angular 1.2.6과 grunt-bower-install 지원
  • Ember.js 0.8.0 버전 릴리즈
    • Ember 1.2 문법에 대한 스캐폴딩 업데이트
    • CoffeeScript 지원
    • 템플릿 기능(Templating)
    • REST 라우터
  • WebApp 0.4.5 및 0.4.6 버전 릴리즈
    • 개선된 HTMLMin 포함
    • bower 인스톨 버그 수정
    • CSS 의존성을 지원하는 grunt-bower-install 포함
  • Polymer 생성기 0.0.8 버전 릴리즈
    • Web Component 연결(Concatenization) 및 다른 업데이트들
  • Chrome app 0.2.5 버전 릴리즈
    • 라이브리로드(Livereload)의 지원 개선
    • 앱 생성기의 재작성
    • 패키징을 위한 빌드 태스크
    • 새로운 권한 코드 등

jQuery, Gruntfile, CommonJS, NodeJS 및 Mocha를 포함한 다른 공식 생성기 역시 업데이트되었습니다.


커뮤니티 위주의 생성기들




요, 새해입니다(yo newyear!)


끝났습니다! 만약 다음 이슈에서 제안하시고 싶은 Yeoman 리소스들이 있다면, 트위터 @yeoman 혹은 구글플러스 +Yeoman에 그것들을 편안하게 제안해주시기 바라며 저희는 반드시 제안된 것들을 확인하도록 하겠습니다. 행복한 연휴되시고 환상적인 새해 맞으시기를 바랍니다!

이 이슈의 리뷰를 해준 Stephen Sawchuk, Sindre Sorhus 그리고 Pascal Hartig에게 특별히 감사드리며...


"Yeoman은 어떠한 프레임워크에 특화된 기반 구조(scaffold)들을  조합 가능한 생성기(Generator)를 이용한 작업흐름을 도와주는 도구입니다. Yeoman에 대해서는 Yeoman과 Polymer를 이용한 웹앱 개발(Building Web Apps With Yeoman And Polymer) 튜토리얼에서 자세하게 다루고 있으니 관심있으신 분들은 참고하시기 바랍니다."

2013년 12월 27일 금요일

[업데이트] 크롬 개발자도구 12월 요약(Chrome DevTools Digest December 2013)

크롬 개발자도구에 대한 요약이 11월 다이제스트에 이어 +Umar Hansa가 작성한 12월 버전이 나왔네요. 이전에는 튜토리얼이었지만 이번은 포스팅으로 제공되어 따로 번역에 대한 링크 없이 이 포스팅에서 전문을 다루도록 하겠습니다.

"여기서 다루는 기능은 기본적으로 크롬 Canary에서 동작합니다. 일반적으로 Official은 대부분 8~10주 뒤에 적용되므로 혼동이 없으시기 바랍니다. Chrome Canary Version은 여기에서 다운로드하시기 바랍니다."


크롬 개발자도구 12월 다이제스트


최근 많은 개선된 기능들이 크롬 개발자도구에 포함되고 있으며 몇 가지는 작은 것이지만 몇가지는 아주 큰 기능들입니다. 오늘은 엘리먼트 패널의 업데이트에 대한 이야기부터 시작하여 콘솔, 타임라인 등으로 주제를 넓혀나가보려 합니다.

비활성화되어 있는 스타일 규칙의 복사가 코멘트처럼 처리


Styles pane에서 전체 CSS 규칙을 복사하는 것은 이제 토글로 꺼둔것을 포함하며 클립보드에는 코멘트처리한 것처럼 존재하게 됩니다. [crbug.com/316532]

CSS 경로로써 복사하기


‘Copy as CSS path’가 이제 엘리먼트 패널의 DOM 노드의 메뉴 아이템에서 사용가능합니다. (Copy XPath 메뉴와 유사합니다.)


CSS 셀렉터의 생성은 여러분의 스타일시트/자바스크립트에 제한되지 않으며 WebDriver 테스트의 로케이터 전략으로 대체될 수도 있습니다.[crbug.com/277286]

쉐도우 DOM 엘리먼트 스타일 보기


이제 쉐도우 루트의 자식 엘리먼트는 별도로 확인 가능한 스타일을 가집니다. [crbug.com/279390]

콘솔의 copy()가 객체에 대해 동작


커맨드라인 API의 copy() 메소드가 이제 객체에 대해 동작합니다. 일단 가서 콘솔 패널에 copy({foo:'bar'})를 입력하고 어떻게 문자열화가 되는지와 객체의 형식화된 버전이 클립보드에 어떻게 남아 있는지 확인하시기 바랍니다. [crbug.com/289348]

콘솔을 위한 정규표현 필터


콘솔 패널에서 정규 표현식을 이용한 콘솔 메시지의 필터가 가능합니다.[crbug.com/318308]

손쉬운 이벤트 리스너 제거


콘솔 패널에서 document의 첫번째 마우스 이벤트 리스너를 검색하기 위해getEventListeners(document).mousewheel[0];를 실행하여 보시기 바랍니다. 계속해서 이벤트 리스너를 제거하기 위해 $_.remove();를 실행하여 보시기 바랍니다.($_는 가장 최근에 평가된 표현의 값입니다.) [crbug.com/309524]

CSS 경고의 제거


"Invalid CSS property value(유효하지 않은 CSS 속성값)"과 같은 스타일 경고는 이제 제거되었습니다. 브라우저의 핵(hack)을 포함하여 실제 CSS에 대해 더 견고한 구현을 만들기 위한 노력은 계속되고 있습니다. [crbug.com/309982]

타임라인 동작의 파이차트 요약



타임라인 패널은 이제 Details pane 내에 렌더링 비용의 소스를 시각적으로 보여주는 파이 차트를 포함합니다. - 이는 슬쩍 보는 것만으로도 성능의 병목지점을 파악하는데 도움을 줄 것입니다.
이제 pane 자체에서 알려주는 팝오버 디스플레이를를 사용하여 더 많은 정보를 발견할 수 있습니다. 이를 보기 위해 타임라인 기록을 시작하고 프레임을 선택하여 파이차트를 포함하는 새로운 Details pane을 보시기 바랍니다. 프레임뷰를 볼 때 평균 FPS (1000ms/프레임)과 같은 흥미로운 상태값을 선택한 프레임에 대해 볼 수 있습니다. [crbug.com/247786]

이미지 리사이즈 이벤트 상세정보


이제 이미지의 리사이즈 및 디코딩 이벤트가 타임라인 패널에 엘리먼트 패널 내의 DOM 노드에 대한 링크를 포함합니다.


이미지 URL 링크는 리소스 패널에서 관련된 리소스를 찾을 수 있도록 해줍니다. [crbug.com/244159]

GPU 프레임


GPU에서 발생하는 프레임들은 이제 최상단 및 메인 스레드 상의 프레임 위에서 보여집니다. [crbug.com/305863]

popstate 리스너 상에서의 브레이크


'popstate'는 이제 Sources panel의 사이드바에서 이벤트 리스너 중단점처럼 사용이 가능합니다. [crbug.com/88112]

렌더링 설정의 서랍(Drawer) 기능


서랍을 열면 이제 많은 pane들이 표시되며 그 중의 하나가 새로 그리는 영역을 표시하는(역주: 이전의 기능에서는 Show paint rectangles로 설정할 수 있는 기능입니다.) 렌더링 패널, FPS 메터기 등입니다. 이것이 이제 설정(Settings) > "Show 'Rendering' view in console drawer"가 가능하도록 기본 설정이 되었습니다.

이미지의 Data URL 복사



리소스 패널의 이미지들은 이제 그들의 컨텐츠를 data URI (data:image/png;base64,iVBO...) 형태로 복사할 수 있습니다. 이를 사용하기 위해서는 Frames > [Resource] > Images에서 이미지 리소스를 찾아 이미지 미리보기 화면에서 오른쪽 클릭으로 컨텍스트 메뉴를 열고 ‘Copy Image as Data URL’를 선택하면 됩니다. [crbug.com/321132]

Data URI 필터링


만약 그것들이 없다고 생각되신다면 Data URIs는 이제 Network 탭에서 걸러내질 수 있습니다.  다른 리소스 필터 타입을 보기 위해서는 필터 아이콘()을 클릭하시기 바랍니다. [crbug.com/313845]

네트워크 타이밍 버그의 수정


만약 이미지가 다운로드되는데 300,000년이 걸린다는 것을 본적이 있으시다면 사과드리겠습니다. ;) 이러한 네트워크 리소스에 대한 잘못된 시간 계산은 이제 수정되었습니다. [crbug.com/309570]

네트워크 기록 동작에 대한 조작성 향상


네트워크 기록 동작이 약간 달라졌습니다. 첫번째로 기록 버튼이 타임라인이나 CPU 프로파일에서 기대하던 것처럼 동작합니다. 그리고 여러분들이 원했던 방식으로 개발자도구가 열려있는 동안 페이지를 리로딩한다면 네트워크 기록은 자동으로 시작할 것입니다. 그리고 나서 자동으로 꺼지므로 페이지 로딩 뒤의 네트워크 동작을 캡쳐하고 싶으시다면 이를 다시 켜시면 됩니다. 이는 여러분의 임시적인 네트워크 요청으로 인한 결과의 왜곡없이 폭포수 모델을 손쉽게 시각화할 수 있도록 해줍니다. [crbug.com/325878]

개발자도구의 테마가 이제 Extension을 통해 가능


사용자의 스타일시트가 개발자도구에 대한 커스텀 스타일을 적용하기 위한 크롬 익스텐션을 허가하는 개발자도구의 실험실 기능("Allow custom UI themes" 체크박스)을 통해 가능합니다. Sample DevTools Theme Extension에서 예제를 보실 수 있습니다. [crbug.com/318566]


개발자도구 요약의 이번 에디션은 여기까지입니다. 기존 것을 보신 적이 없으시다면 11월 에디션도 확인해보시기 바랍니다.

참조 링크

2013년 12월 23일 월요일

[업데이트] 블링크의 CSS 애니메이션/트랜지션 엔진이 웹 애니메이션으로 대체되었습니다.

이미 이에 대해 포스팅한 바를 보셨을 것입니다. Web Animaiton은 기존의 CSS 애니메이션 및 트랜지션, SVG 애니메이션과 SMIL 등 기존의 애니메이션 요소를 자바스크립트로 동적 제어가 가능하도록 정의하고 있는 새로운 애니메이션 규격입니다. -그렇다고 해서 아주 새로운 것은 아닙니다. 기존 CSS 애니메이션/트랜지션이나 SVG, SMIL 등의 기존 기술에 대한 '제어'를 주된 목표로 두고 있다고 이해하셔도 무방합니다.-

이에 대한 시작으로 Web Animations의 자바스크립트 API 구현을 참조할 수 있는 Polyfill 라이브러리인 web-animtations.js이 진행되고 있습니다. 현재 블링크(Blink)에는 이 기능을 네이티브로 구현하는 작업이 진행 중인데 이에 대한 첫 단계로 크롬 카나리에서 기존 CSS 애니메이션과 트랜지션 엔진이 Web Animation 구현 엔진으로 대치되어 배포되고 있습니다.

현재는 JS API가 존재하지 않으므로 외부에서는 차이점을 느끼기 힘들겠지만 대략 2월 말에는 공식 버전으로도 배포가 될 예정입니다. (물론 이는 JS API를 포함하지는 않습니다.) 아래는 HTML5Rocks에 +Alex Danilo 가 올린 업데이트 'New Web Animations engine in Blink drives CSS Animations & Transitions'에 대한 번역입니다. 실제 API의 구현 및 동작에 대해서는 아래 참조 링크에서 확인하시기 바랍니다. :)


전문


사용자들은 멀티 디바이스 UI들에 대해 부드러운 60fps 애니메이션을 기대합니다. 웹의 현재 애니메이션 기본형을 가지고 그러한 성능 품질을 달성하는 것은 어려울 수 있습니다. 다행히도 Blink의 새로운 애니메이션을 구현하고 있으며 크롬 카나리에 막 탑재되었습니다!

블링크의 내부가 단순화되고 Web Animation 1.0 규격의 새로운 API 기능을 포함하는 바탕이 마련된 것에 대해 매우 기쁘게 생각합니다.

지금까지 CSS 애니메이션과 CSS 트랜지션은 분리되어 구현되었으며 독립적으로 작성되어 동시에 재생할 필요가 없었습니다. 지난 몇년간 브라우저 구현자들은 동기화나 애니메이션 체인, 순차적으로 재생되고 애니메이션의 특정한 위치로의 이동, 애니메이션의 재생 속도 변경이나 역재생 등과 같은 것을 지원하는 다음 세대의 애니메이션 모델을 위해 일해왔습니다. 이러한 노력이 W3C의 Web Animations 1.0을 정립하도록 하였습니다.

블링크팀은 Web Animation을 세상에 내보이기 위한 첫 걸음으로 기존 블링크의 CSS 애니메이션/트랜지션에 대한 C++ 구현을 Web Animaiton 엔진으로 대치하는 것입니다. 현재 그 마일스톤에 도달하여 많은 개발자들이 아무것도 깨지지 않고 구현에 매진하는 것이 더 중요하며, 무엇이 좋아졌고 나쁜지나 변경이 필요한 부분에 대한 피드백을 주기를 원하고 있습니다.

다음은 자바스크립트로 애니메이션의 생성, 변경, 조회를 제공하는 API의 구현이 될 것입니다. API는 여전히 자바스크립트 개발자에게 완전한 애니메이션 제어를 보여주면서 애니메이션이 (선언적인 문법을 사용하여 자바스크립트가 애니메이션을 생성하는 것을 관리하고 브라우저가 이를 컨트롤하여) 더 효율적으로 동작할 수 있도록 합니다.

우리는 강력한 애니메이션 조작을 위해 필요한 어떠한 기능도 놓지지 않았음을 확신하기 위해 제안된 API에 대한 활발한 피드백을 찾고 있습니다. 어떠한 새로운 기능이나 규격이라도 변경이 지속되고 있으므로 이제 여러분의 목소리를 들을 시간입니다. - public-fx@w3.org 메일링 리스트를 구독하고 기여하는 것이 이상적입니다. (그리고 제목에 [Web Animations]를 넣어주시면 효과적입니다.)

이미 CSS 애니메이션과 트랜지션을 강력하게 하고 있는 새로운 엔진을 지금 사용해보시고 어떤 이상한 점이라도 Chromium 버그 트래커에 포스팅해서 알 수 있도록 해주시기 바랍니다. 우리는 차세대 애니메이션 역량을 블링크로 제공하고 또한 새로운 모델의 구현에 커밋한 웹킷과 모질라와 같은 다른 브라우저 개발자와 일할 수 있기를 기대합니다.

참조링크

2013년 12월 18일 수요일

[튜토리얼/한글화] 레이서 게임의 구축(Case Study: Building Racer)

HTML5Rocks '사례연구: 레이서 게임의 구축(Case Study: Building Racer)' 한글 튜토리얼이 업데이트되었습니다.

이전 튜토리얼인 사례연구: Racer의 사운드(Case Study: The Sounds of Racer)에서는 레이서 게임 내의 사운드 구축을 위한 개발 과정과 기술에 대해서 다루었습니다면 이번 튜토리얼에서는 게임을 구축하기 위한 나머지 과정, 특히 렌더링에 대한 내용을 주로 다루고 있습니다. HTML5 게임이나 인터랙티브 컨텐츠를 개발하시거나 계획 중이시라면 읽어보시면 좋을 듯 합니다. 이번 번역은 신현진님(+Hyunjin Shin)께서 수고해주셨습니다.  :)




TL;DR;


레이서는 5명의 친구가 폰이나 태블릿을 이용하여 게임을 진행할 수 있도록 Google Creative Lab과 Plan8의 사운드를 기반으로 8주간 진행되어 Google I/0 2013에서 발표된 실제 이론에 기반한 웹 기반 크롬 실험 형태의 게임입니다. 이번 글에서는 개발자 커뮤니티에서 주로 질의되었던 몇가지 동작 방식에 대한 내용과 레이서의 주요 기능 및 질의 사항에 대한 응답을 정리하였습니다.

트랙을 그리기 위해 해상도를 설정하고 이를 그리기 위한 로직, CSS 애니메이션과 CSS 스프라이트를 통한 렌더링 팁, 실제 게임 내에서 자동차를 렌더링하기 위해 트랜스폼을 어떻게 사용하였는지와 실제 디바이스 간의 동기화를 위해 지연 시간을 계산하고 이를 보정한 방법을 실제 코드와 함께 설명합니다.

아래는 그 중 일부 중요한 내용만 따로 차용한 것입니다.
  • 모바일 디바이스의 해상도 변화에 대응하기 위한 해상도 설정
  • CSS 스프라이트시트를 이용한 스프라이트 애니메이션
  • 궤적의 변화에 따른 애니메이션 처리를 위한 실시간 트랜스폼 연산 및 적용
  • 동기화를 위한 지연 시간의 계산 및 라운드 트립
자세한 내용은 본문을 참조하시기 바랍니다.

번역 링크

참고 글

2013년 12월 16일 월요일

[튜토리얼/한글화] 자바스크립트 Promise: 또 다른 시작(JavaScript Promise: There and Back Again)

HTML5Rocks에 내리는 눈과 함께 기대했던 +Jake Archibald 의 "자바스크립트 Promise: 또 다른 시작(JavaScript Promise: There and Back Again)"이 업데이트되었습니다.
"참고로 There and Back Again은 영화 The Hobbit 3부작 중 마지막 편의 제목이기도 합니다. 뜻밖의 여정, 스마우그의 폐허는 일단 나왔으니 이어서 붙인 장난스러운 제목일지도 모르겠군요. :)"
자바스크립트의 비동기 동작으로 인해 콜백이 콜백을 부르고 다시 콜백이 콜백을 부른 과정이 중첩되다보면 내가 콜백인지 콜백이 나인지 헷갈릴 정도의 Callback Hell에 빠지게 됩니다. Promise는 이러한 비동기 동작을 손쉽게 처리할 수 있도록 고안된 비동기 프로그래밍 모델입니다.

이번 튜토리얼은 거의 작정하고 만든 듯이 완벽 해설서에 가깝습니다. Polyfill을 이용해서 당장 적용해보실 수도 있으니 비동기 콜백에 지치거나 그 지옥 한가운데에 있으시다면 잠시 코딩을 멈추시고 일단 읽어보시길 바랍니다.



TL;DR;


이 글은 브라우저의 지원 사항 및 Polyfill 소개, 다른 라이브러리와의 호환성, 복잡한 비동기 코드를 쉽게 만들기, XMLHttpRequest의 Promise화, Promise 객체의 체이닝(Chaining) 및 에러 핸들링, 병렬과 시퀀싱, Promise API 레퍼런스 등에 대해 다루며 이에 대한 예제들이 포함되어 있습니다. 지금까지 나온 Promise 관련 튜토리얼 중에 가장 자세한 내용이 아닐까 싶네요.


  • 이벤트는 비동기적인 모듈의 동작 결과를 처리하는 최고의 방법 중의 하나입니다만 콜백 형태의 호출이 꼬리를 물어가는 콜백 지옥(Callback Hell)에 빠지게 되는 것은 개발자에게는 일종의 불행과도 같습니다. Promise는 이를 순차적인(동기화)된 듯한 개발 방법을 제공합니다. 코드가 읽기 쉬워지고 콜백의 분기처리를 익숙한 순차적인 처리가 가능해지기 때문에 복잡한 콜백이 얽히는 과정에는 훌륭한 모델을 제공할 수 있습니다.
  • Promise에 대한 개념을 잡아보고 현재 브라우저 지원 상황 및 대체 라이브러리(Polyfill), 다른 라이브러리들과의 호환성을 소개합니다.
  • 실제 예제로는 복잡한 비동기 코드를 좀더 쉽게 만들기 위한 코드를 예제로 동기화된 모듈로부터 비동기화된 모듈, 그리고 최종적으로는 Promise화된 모듈의 구현 사항들을 순서대로 진행합니다.
  • 이 과정에서 Promise의 연결을 구현하는 체이닝(Chaining)과 에러 핸들링, 그리고 비동기적인 처리를 동시 수행하면서 필요한 로직을 Promise를 통해 순차적으로 처리하는 방법을 다루고 Promise API 레퍼런스를 수록하고 있습니다.


튜토리얼 링크

[업데이트] 안드로이드 버전 32부터 300ms 탭 딜레이 제거 가능!

전통적으로 모바일 브라우저는 PC의 그것과는 조금 다른 300ms의 클릭 딜레이를 가져왔습니다. PC의 경우 주로 마우스를 사용하였으므로 사실 클릭의 딜레이는 시스템에 따라 더블클릭을 구분하기 위한 시간차 정도였거나 없는 경우가 대다수였습니다만 터치를 기반으로 하는 모바일 디바이스의 경우 사용자의 탭 제스쳐 자체가 이후의 많은 연결 동작(예를 들어 스크롤, 핀치 줌 등)과의 이슈가 존재했습니다.



이러한 300ms의 딜레이가 모바일 디바이스에서 웹 사용자들에게 미묘하고 지속적으로 늦은 반응을 인식하게 만든 장본인이기도 합니다. 아무튼 시스템이 다음 동작을 판별하기 위한 일반적인 시간 딜레이값이 300ms 였습니다만 사용자가 핀치 줌 제스처를 이용하는 것을 비활성화함으로써 Chrome For Android Version 32부터 이를 제거할 수 있습니다.


간략하게 정리하면 다음과 같은 선결 조건이 있습니다.

  • Chrome For Android version 32 이상 혹은 Firefox for Android
  • 다음과 같이 메타 태그를 통해 핀치 줌(Pinch Zoom) 제스처를 사용하는 사용자 스케일을 막을 것

<meta name="viewport" content="width=device-width, user-scalable=no">

참조링크


"마이크로소프트에서 제안했던 Pointer 이벤트(터치와 마우스를 동시에 지원하는 이벤트 규격)에 브라우저 벤더들이 동의를 하는 것 같은데 표준안 처리 이전에라도 빠르게 다른 브라우저에서도 구현되었으면 좋겠네요."

2013년 12월 13일 금요일

[튜토리얼/한글화] 중간계의 프론트엔드: 멀티디바이스 개발의 여정(The Front-end of Middle-earth: A walkthrough of multi-device development)

HTML5Rocks에 새로운 튜토리얼 "중간계의 프론트엔드: 멀티디바이스 개발의 여정(The Front-end of Middle-earth: A walkthrough of multi-device development)"이 등록되었습니다.

이전에 게시되었던 튜토리얼이 모바일 상에서 WebGL, 3D Transform, 성능 최적화에 대한 개괄적인 접근을 다루었다면 이번 튜토리얼은 멀티 디바이스(PC, 태블릿, 폰)에 대한 직접적인 개발 방법을 논의하고 있습니다.

"오늘이 호빗의 개봉일이네요. 영화만큼이나 흥미로운 튜토리얼, 잘 감상하시길..."


TL;DR;


이전 튜토리얼이 모바일에서의 WebGL을 주로 다루었다면 이번 글은 나머지 HTML5 프론트엔드의 구현 사항에 대한 여러가지 이슈들과 해결 방법들에 대해 논의합니다.

멀티 디바이스 지원을 위한 스타일의 정의, 페이지의 전환을 위한 기법들, 랜딩 페이지를 다루기 위한 History API의 사용, 풀스크린의 지원, 애니메이션 시퀀스와 그 처리 방법, 리소스의 최적화, 페이지 성능 등에 대해 실제적인 사례를 기반으로 설명하고 있습니다. 실제 사이트를 참고하시면서 보시면 도움이 되리라 생각합니다.

튜토리얼 링크

2013년 12월 10일 화요일

[튜토리얼/한글화] 크롬의 렌더링 가속: 레이어 모델(Accelerated Rendering in Chrome : The Layer Model)

HTML5Rocks '크롬의 렌더링 가속: 레이어 모델(Accelerated Rendering in Chrome : The Layer Model)' 한글 튜토리얼이 업데이트되었습니다.

최근 제가 렌더링 최적화에 대한 튜토리얼은 되도록이면 이전 것들까지 번역하려고 노력하고 있는데 레이어(Layer) 모델은 브라우저가 렌더링을 하기 위한 동작에 대해 이해하는 가장 기초적인 개념이 될 것입니다. 이와 더불어 3D 그래픽스에 대한 약간의 지식만으로도 훨씬 더 나은 하드웨어 가속 렌더링에 대한 이해가 가능하므로 읽어보시기를 권장합니다.




TL;DR;


대다수의 웹 개발자들에게 웹 페이지의 일반적인 모델은 DOM이며  렌더링은 일반적으로 이러한 페이지의 표현 형태를 화면상의 이미지로 변환하는 과정입니다. 모던 브라우저들은 이 렌더링에 있어 최근 몇년동안 "하드웨어 가속"이라고 불리는 성능적 뒷받침을 받기 위해 노력해왔습니다.  이 글은 크롬에서 웹 컨텐츠의 하드웨어 가속 렌더링의 기반이 되는 기본 모델에 대해 설명합니다.

아래는 그 중 일부 중요한 내용만 따로 차용한 것입니다. 자세한 내용은 본문을 참조하시기 바랍니다.

DOM의 스크린 출력을 위한 개념적인 과정

  • DOM을 레이어들로 분리
  • 개별 레이어를 비트맵으로 출력
  • GPU 텍스쳐로 업로드
  • 다양한 레이어의 합성을 통해 스크린 출력


레이어(Layers)

  • DOM 구조는 렌더링할 때 브라우저는 개발자에게 직접 보여지지 않는 중간 표현의 연속 과정을 가지게 됩니다. 이 구조들 중 가장 중요한 것은 레이어입니다.
  • 레이어의 컨텐츠를 소프트웨어 비트맵으로 출력하여 GPU에 텍스쳐로 업로드
  • 업로드 후 합성(Composition)에 해당하는 렌더링은 가속됨


레이어 사용상의 주의점

  • 시스템과 GPU의 메모리의 낭비
  • 가시성 추적에 의한 로직 상의 부하
  • 레이어의 숫자/크기/겹침에 따른 픽셀화(Rasterizing)에 소모되는 시간의 증가 등


번역 링크

[튜토리얼/한글화] 사례연구: Racer의 사운드(Case Study: The Sounds of Racer)

HTML5Rocks '사례연구: Racer의 사운드(Case Study: The Sounds of Racer)' 튜토리얼이 업데이트되었습니다.

웹에서 오디오나 비디오는 사실 플래시만큼이나 애증의 대상입니다. 웹 컨텐츠를 가장 쉽게 풍성하게 보여주기도 하지만 그만큼이나 컨트롤은 어렵습니다. 이 튜토리얼은 슬롯 트랙에서 플레이되는 자동차 게임인 '레이서(Racer)'의 사운드 구현에 관련된 내용들을 담고 있습니다. 사실 오디오와 관련해서 웹 상에서 많은 리소스들이 있지는 않기 때문에 웹 오디오로 고민하시는 분들에게는 도움이 되리라 생각합니다. 특이한 구현 사례도 있고 많지는 않지만 오디오에 대한 지식도 조금 필요하기 때문에 필요한 부분만 읽으셔도 좋고 멀티미디어 컨텐츠 혹은 게임 개발자시라면 자세하게 읽어보시길 권해드립니다.

이번 번역은 +Hyunjin Shin님이 수고해주셨습니다. :)



TL;DR;


Racer Racer는 멀티플레이어 및 멀티디바이스로 동작하는 크롬 실험입니다. 여러개의 스크린에서 플레이하는 레트로 스타일의 슬롯 자동차 게임입니다. Android, iOS 폰 또는 태블릿에서 동작하며 누구나 참여할 수 있습니다. 앱이 아니며 다운로드도 없는 그저 모바일 웹일 뿐입니다.

이 게임은 다수의 사용자가 게임에 참가하고 참가한 사람들의 휴대폰을 일종의 다중 스피커로 활용합니다. 드럼과 베이스로 시작되어 기타와 신디사이저 등이 추가되는 음악 트랙이 만들어지는 형태입니다. 이 게임을 만들기 위해 필요한 내용을 다음과 같이 정리/제공합니다.

  1. 여러 개의 오디오 파일을 동기화하여 이용한 엔진 사운드의 구현 방법
  2. 버스트 요청을 샘플링하고 그것을 기준으로 낮은 레이턴시를 계산하여 네트워크를 통한 음원 재생 동기화
  3. 지연 누적으로 인해 긴 시간 동안 재생 후에 음악 레이어에서 전체적으로 동기화가 틀어지는 클럭 드리프트에 대한 해결
  4. 동적인 상태 변화를 위한 노래 스케줄링 및 오디오 재생 순서의 배치 전환 및 최적화
  5. 하나의 오디오 파일을 스프라이트처럼 응용한 오디오 스프라이트 사례

참고 글

[튜토리얼/한글화] 개발자도구에서 터미널 사용하기(Using Your Terminal From The DevTools)

+Addy Osmani의 '개발자도구에서 터미널 사용하기(Using Your Terminal From The DevTools)' 튜토리얼이 업데이트되었습니다.

웹 개발을 하다보면 터미널을 반복적으로 사용하게 되는 경우가 있으며 특히 Grunt나 별도의 빌드 및 배치 시스템을 가진 경우는 더 그렇습니다. 이번 튜토리얼은 크롬 개발자도구의 기능/실험실이 아닌 개발자도구에서 터미널을 사용할 수 있게 해주는 작지만 편리한 크롬 확장기능(Extension)입니다. 특히나 금번 튜토리얼은 소개에 가까우므로 커맨드라인 도구를 자주 쓰시는 분들은 한번 참조해보셔도 좋을 듯 합니다.

참고로 윈도우즈 사용하시는 분들은 별도의 문제점이 있는지 댓글 달아주실 수 있을까요? 며칠 전에 알려드린 한분이 자신은 윈도우라서 안되는 것인지 모르겠다고 하셨는데 조금 궁금하네요. :)



TL;DR;


크롬 개발자도구에서 터미널을 지원하는 것은 몇가지 이점이 있습니다. 브라우저와 편집기, 터미널을 오가며 바쁘게 컨텍스트를 변경하는 것보다는 같은 창 내에서 이를 진행하는 것이 효율적일 것입니다. 아래는 개발자도구와 터미널을 통합하여 사용하는 예입니다.

  1. 작업영역(Workspaces)
    1. 크롬 내의 웹앱을 편집하고 디버깅
    2. 서버 실행 시 로컬 프로젝트와 네트워크 파일들의 매핑
  2. 개발자도구 터미널
    1. git, yeoman과 같은 커맨드라인 기능 실행
    2. 앱을 미리보기 위한 새로운 서버를 실행
    3. 소스 컨트롤에 커밋
    4. 의존성 모듈들을 내려받기 위해 (npm, bower 같은) 패키지 관리자 사용
    5. (grunt, make 같은) 빌드 프로세스를 실행
제한점들
  • 다중 탭(Tab), 다중 윈도우, 뒤로가기(History playback)를 지원하지 않습니다.
    • 새로운 인스턴스를 여러개 띄우는 것으로 이를 대치할 수는 있습니다.
크롬을 통해 웹페이지 테스트를, 개발자 도구로 개발 및 디버깅을, 이 확장기능을 이용하여 터미널 빌드를 사용하는 것을 시도해보시기 바랍니다.

참고 글

2013년 12월 4일 수요일

[튜토리얼/한글화] 모바일을 위한 크롬 개발자도구: 스크린캐스트와 에뮬레이션(Chrome DevTools for Mobile: Screencast and Emulation)

+Paul Irish의 HTML5Rocks의 '모바일을 위한 크롬 개발자도구: 스크린캐스트와 에뮬레이션(Chrome DevTools for Mobile: Screencast and Emulation)' 튜토리얼이 업데이트되었습니다.

지난번 크롬 개발자 데이 이후부터 중간중간 크롬 개발자도구에서 직접적인 원격 디버깅과 화면 공유에 대해 이야기한 적이 있었는데 이번에는 그 모바일 디바이스에 대한 리모트 디버깅 시 유용하게 사용할 수 있는 '스크린캐스트(ScreenCast)'와 디바이스가 없거나 번거로울 때 사용할 수 있는 '에뮬레이션(Emulation)'에 대해 설명합니다. 모바일 개발자인데 모르고 계셨다면 꼭 읽으시길 추천해드립니다. :)



TL;DR;


모바일을 위해 개발하는 것은 데스크탑을 위해서 개발하는 것과 거의 비슷합니다. 이 글은 크롬 개발자도구에서 모바일 웹 개발 과정에서 디버깅을 크게 개선할 수 있는 새로운 기능인 리모트 디버깅(Remote Debugging)과 모바일 에뮬레이션(Emulation)에 대해 설명합니다.

  • 리모트 디버깅 - 디바이스에 대한 원격 디버깅
    1. 별다른 설정없이 간단한 과정으로 디바이스의 안드로이드 크롬에 직접 연결하여 디버깅을 지원합니다.
    2. 스크린캐스트(ScreenCast)를 이용하여 실제 디바이스 화면을 보지 않고 크롬 개발자도구에서 화면을 보고 인터랙션할 수 있습니다.
    3. (즉, 디바이스에서 직접 접근할 IP나 도메인이 없거나 불명확하게) 로컬호스트 등에서 실행되는 경우에도 포트 포워딩(Local Port Forwarding)로 이를 지원합니다.
  • 에뮬레이션 - 디바이스가 없을 경우의 에뮬레이션 및 디버깅
    1. 디바이스가 없을 경우에 화면 크기, devicePixelRatio, 메타 뷰포트 및 풀터치 이벤트에 대한 시뮬레이션을 지원합니다.
참고하시기 바랍니다.

참고 글

2013년 12월 2일 월요일

[튜토리얼/한글화] 크롬 개발자도구 11월 요약(Chrome DevTools November Digest)

HTML5Rocks의 '크롬 개발자도구 11월 요약(Chrome DevTools November Digest)' 튜토리얼이 업데이트되었습니다.

이제 크롬 개발자도구의 업데이트에 대한 요약이 주기적으로 이루어질 것 같네요. 매번 매뉴얼을 살펴보기 힘들거나 이미 개발자도구를 잘 사용하고 계시는 분이라면 이 다이제스트를 지속적으로 읽어보시는 것으로 신규 기능을 참조하시기 바랍니다.



TL;DR;


크롬 개발자도구는 빠르게 발전하고 있어 새로운 기능이나 개선점들에 대해 지속적인 안내가 필요합니다. 이글은 몇 가지 UI의 변경점들과 고해상도 자바스크립트 프로파일링, 새로운 작업공간(Workspace) 기능에 대해 설명합니다.


  1. 고해상도 프로파일링이 이제 .1ms 단위로 동작 가능합니다.
  2. 툴바가 개발자도구 상단에 위치하며, Overrides가 콘솔 드로어(Drawer)로 이동하였습니다.
  3. 파일을 추가/삭제/검색을 지원하는 몇가지 기능이 작업공간(Workspace)에 추가되었습니다.
이외에도 새로고침(refresh)를 좀 더 쉽게 호출할 수 있도록 context menu가 간소화되었네요. 참고하시기 바랍니다.

참고 글

[튜토리얼/한글화] 동기화된 크로스 디바이스 모바일 테스팅(Synchronized Cross-device Mobile Testing)

HTML5Rocks의 '동기화된 크로스 디바이스 모바일 테스팅(Synchronized Cross-device Mobile Testing)' 튜토리얼이 업데이트되었습니다.

다양한 모바일 디바이스에서 동시에 웹 페이지를 테스트할 때 사용 가능한 동기화 도구를 설명합니다. 개발자뿐만이 아니라 특히 웹 페이지의 수동 테스팅을 주업무로 하는 분들(QA 같은)이 읽어보시면 도움이 될 듯 합니다.



TL;DR;


모바일 디바이스는 이제 너무나도 많고 다양한 스펙 및 종류를 포함하고 있습니다. 특히 HTML5를 대상으로 하는 모바일 페이지의 경우 아직 정립되지 않은 개발 내용을 포함하는 경우도 있습니다. 이러한 디바이스에서 자주 수동 테스팅을 하는 경우 동일한 작업에 대한 시간적인 낭비가 심합니다. 이것을 어떻게 간소화할 수 있을까요?

이 글은 다양한 동기화 도구를 통해 동시에 다양한 디바이스에서의 수동 테스팅 방법을 설명합니다. 여러개의 도구를 설명하므로 상황에 맞추어 참고하시면 되겠습니다. 이 글에서 설명하는 도구는 다음과 같습니다.

  1. Ghostlab (Mac)
  2. Adobe Edge Inspect CC (Mac, Windows)
  3. Remote Preview (Mac, Windows, Linux)
  4. Grunt + Live-Reload (Mac, Windows, Linux)
  5. Emmet LiveStyle

참고 글