조금 많이 늦었지만 올초 열렸던 FITC Toronto 2009의 비디오 프레젠테이션들을 이제야 보았습니다.
FITC의 프레젠테이션들은 너무 길어서 지루하네요, 질도 높이고 시간을 줄여서 역동적으로 만들면 참 좋을 듯 싶네요.
이런 멋진 커뮤니티가 있는게 부럽네요.
아무튼 제게 가장 흥미로웠던 세션은 새로운 플래시 플래이어의 내부에 대해서 조금 더 알게 해 주었던 Jim Corbett의 Flash Player Internals v2 이었습니다.
v1 프레젠테이션에서 몰랐던 많은 사실을 알게 되었어서 기대를 많이 했습니다.
흥미로운 몇 가지를 적어 보도록 하겠습니다.
Grant Skinner에 의해서 제기되서 구현했다는 Loader.unloadAndStop() 관한 것입니다.
AS3에서 load한 무비 클립을 unload 해도 그 로드 되었던 무비 클립이 사용했던 사운드, 이벤트 핸들러, 자식 무비 클립들은 그 로드된 무비클립에서 제대로 처리해주지 않으면 그대로 메모리에 남게 됩니다. 로드 되는 무비 클립이 본인이 제작할 수 있는 것이라면 고쳐 주면 되겠지만, 다른 제작자들의 swf를 그냥 로드해야 하는 경우엔 어쩔 도리가 없습니다. 그 때 이 unloadAndStop()를 호출하면 로드된 무비 클립의 자식 디스플레이 노드들을 돌면서 사운드도 죽이고, 핸들러도 없애고, 언로드 시킨다고 합니다.
그냥 unload 함수를 고치지 않고 새로 함수를 만든 이유는 호환성 때문이랍니다.
Details
요즘은 타임라인을 거의 안 써서 전혀 몰랐던 내용이네요.
타임라인에 onEnterFrame 리스너가 있고 프레임에 어떤 무비 클립을 추가 할 경우, 위의 그림 처럼 AS2에서는 생성 되는 무비 클립의 생성자가 먼저 호출 되고 onEnterFrame, 프레임 액션, 그리고 프레임을 렌더링 하는데 반해, AS3에서는 같은 상황에서 enterFrame 이 먼저 호출 되고 생성자가 나중에 호출 되는 데, 버그 였답니다.
그래서 고치려다가 이미 만들어진 컨텐츠들과의 호환성을 위해 그냥 놔두고 2개의 새로운 이벤트를 추가 했답니다.
그게 frameConstructed와 exitFrame 이라는 군요, 그러니깐 AS2의 onEnterFrame과 같은 타이밍이 필요한 경우 AS3에서는 frameConstructed를 사용해야 한답니다.
호환성을 이유로 너무 막 나가는게 아닌지?
wmode에 새로운 2개의 모드가 추가 되었습니다. gpu와 direct. 이 부분은 저도 많이 궁금하던 것인데 사용하는 컴퓨터가 오래 되서 gpu 가속을 테스트 할 길이 없네요.
gpu와 direct가 어떻게 다른지는 암만 읽어도 애매모호 하네요.
둘다 OpenGL, Direct3D를 쓰는데, gpu는 그래픽 카드의 몇 가지 기능을 사용한다고 하네요.
정말 두리뭉실한 설명이네요.
프레젠테이션에서는 간단한 소프트웨어 렌더러와 하드웨어 렌더러 차이를 겹칩이 있는 경우로 설명합니다. 예를 들어 한 무비클립이 다른 무비 클립 위에 위치할 때 소프트웨어 렌더러는 화면에 비춰질 영역만 계산해서 그리는데 반해 하드웨어는 전부 그리고 그 위에 다시 그린다고 합니다. 하드웨어적으로 훨씬 빠르기 때문에 그런 계산이 필요 없는 것이겠죠. 3D 엔진도 예전에는 BSP Tree등을 이용해 소프트웨어 렌더러 성능을 향상시켰지만, 하드웨어 렌더러 들은 그런 것 없이도 더 빠른것과 같은 이치겠지요.
윈도우에서는 DirectX 9를 지원하는 카드가 있어야 제대로 사용할 수 있답니다. 윈도우 vista의 Aero glass와 같은 기능들을 쓴다고 합니다. GPU 모드를 쓴다고 반드시 빨라 지는 것도 아니라니 하드웨어에 별 관심도 없어서 고만해야 겠군요.
사실 정작 궁금했던 것은 Flash CS4에서 Publish 할 경우, Gpu, Direct 냐에 따라 wmode의 코드도 바뀌지만 컴파일된 swf 파일도 역시 바뀐 다는 것입니다. 정확히 한 바이트로 위치는 17H 인데, 관련 태그가 분명한데, swf specification에도 관련 내용은 없네요. 독립 실행이나 AIR용 인거 같은데, Adobe 얘네들은 맨날 뭘 숨기더라. 내가 못 찾은 건가?
Details
캐캐 묵은 플래시의 SEO 에 관한 이슈를 해결하려고 진행중인 프로젝트 설명입니다. 이 문제 정말 오래 되었죠.
검색을 좀 더 가능하게 하기 위해서 Google과 같이 작업하고 있다는 얘기는 들었는데 자세히 듣기는 처음이네요. 이 부분은 나중에 더 알아 보고 따로 포스팅 해야 겠습니다. 간략히 프레젠테이션에 따르면 Google 검색기가 가상 유저로 swf 파일을 로드 해서 프레임 돌아 다니며 버튼도 다 눌러 보고 텍스트들을 다 찾아 낸다고 합니다. 괜히 어설프게 사장님 욕 같은 거 에스터 에그로 넣어 놔도 구글이 다 끄집어 낸다는 얘기 겠죠. 검색이 잘 되도록 하려면 SWFObject이나 Adobe detection code를 사용하라고 합니다.
FITC의 프레젠테이션들은 너무 길어서 지루하네요, 질도 높이고 시간을 줄여서 역동적으로 만들면 참 좋을 듯 싶네요.
이런 멋진 커뮤니티가 있는게 부럽네요.
아무튼 제게 가장 흥미로웠던 세션은 새로운 플래시 플래이어의 내부에 대해서 조금 더 알게 해 주었던 Jim Corbett의 Flash Player Internals v2 이었습니다.
v1 프레젠테이션에서 몰랐던 많은 사실을 알게 되었어서 기대를 많이 했습니다.
흥미로운 몇 가지를 적어 보도록 하겠습니다.
- Loader.unloadAndStop()
Grant Skinner에 의해서 제기되서 구현했다는 Loader.unloadAndStop() 관한 것입니다.
AS3에서 load한 무비 클립을 unload 해도 그 로드 되었던 무비 클립이 사용했던 사운드, 이벤트 핸들러, 자식 무비 클립들은 그 로드된 무비클립에서 제대로 처리해주지 않으면 그대로 메모리에 남게 됩니다. 로드 되는 무비 클립이 본인이 제작할 수 있는 것이라면 고쳐 주면 되겠지만, 다른 제작자들의 swf를 그냥 로드해야 하는 경우엔 어쩔 도리가 없습니다. 그 때 이 unloadAndStop()를 호출하면 로드된 무비 클립의 자식 디스플레이 노드들을 돌면서 사운드도 죽이고, 핸들러도 없애고, 언로드 시킨다고 합니다.
그냥 unload 함수를 고치지 않고 새로 함수를 만든 이유는 호환성 때문이랍니다.
Details
- Timeline Improvements
요즘은 타임라인을 거의 안 써서 전혀 몰랐던 내용이네요.
타임라인에 onEnterFrame 리스너가 있고 프레임에 어떤 무비 클립을 추가 할 경우, 위의 그림 처럼 AS2에서는 생성 되는 무비 클립의 생성자가 먼저 호출 되고 onEnterFrame, 프레임 액션, 그리고 프레임을 렌더링 하는데 반해, AS3에서는 같은 상황에서 enterFrame 이 먼저 호출 되고 생성자가 나중에 호출 되는 데, 버그 였답니다.
그래서 고치려다가 이미 만들어진 컨텐츠들과의 호환성을 위해 그냥 놔두고 2개의 새로운 이벤트를 추가 했답니다.
그게 frameConstructed와 exitFrame 이라는 군요, 그러니깐 AS2의 onEnterFrame과 같은 타이밍이 필요한 경우 AS3에서는 frameConstructed를 사용해야 한답니다.
호환성을 이유로 너무 막 나가는게 아닌지?
- New wmodes
wmode에 새로운 2개의 모드가 추가 되었습니다. gpu와 direct. 이 부분은 저도 많이 궁금하던 것인데 사용하는 컴퓨터가 오래 되서 gpu 가속을 테스트 할 길이 없네요.
gpu와 direct가 어떻게 다른지는 암만 읽어도 애매모호 하네요.
둘다 OpenGL, Direct3D를 쓰는데, gpu는 그래픽 카드의 몇 가지 기능을 사용한다고 하네요.
정말 두리뭉실한 설명이네요.
프레젠테이션에서는 간단한 소프트웨어 렌더러와 하드웨어 렌더러 차이를 겹칩이 있는 경우로 설명합니다. 예를 들어 한 무비클립이 다른 무비 클립 위에 위치할 때 소프트웨어 렌더러는 화면에 비춰질 영역만 계산해서 그리는데 반해 하드웨어는 전부 그리고 그 위에 다시 그린다고 합니다. 하드웨어적으로 훨씬 빠르기 때문에 그런 계산이 필요 없는 것이겠죠. 3D 엔진도 예전에는 BSP Tree등을 이용해 소프트웨어 렌더러 성능을 향상시켰지만, 하드웨어 렌더러 들은 그런 것 없이도 더 빠른것과 같은 이치겠지요.
윈도우에서는 DirectX 9를 지원하는 카드가 있어야 제대로 사용할 수 있답니다. 윈도우 vista의 Aero glass와 같은 기능들을 쓴다고 합니다. GPU 모드를 쓴다고 반드시 빨라 지는 것도 아니라니 하드웨어에 별 관심도 없어서 고만해야 겠군요.
사실 정작 궁금했던 것은 Flash CS4에서 Publish 할 경우, Gpu, Direct 냐에 따라 wmode의 코드도 바뀌지만 컴파일된 swf 파일도 역시 바뀐 다는 것입니다. 정확히 한 바이트로 위치는 17H 인데, 관련 태그가 분명한데, swf specification에도 관련 내용은 없네요. 독립 실행이나 AIR용 인거 같은데, Adobe 얘네들은 맨날 뭘 숨기더라. 내가 못 찾은 건가?
Details
- Search Player
캐캐 묵은 플래시의 SEO 에 관한 이슈를 해결하려고 진행중인 프로젝트 설명입니다. 이 문제 정말 오래 되었죠.
검색을 좀 더 가능하게 하기 위해서 Google과 같이 작업하고 있다는 얘기는 들었는데 자세히 듣기는 처음이네요. 이 부분은 나중에 더 알아 보고 따로 포스팅 해야 겠습니다. 간략히 프레젠테이션에 따르면 Google 검색기가 가상 유저로 swf 파일을 로드 해서 프레임 돌아 다니며 버튼도 다 눌러 보고 텍스트들을 다 찾아 낸다고 합니다. 괜히 어설프게 사장님 욕 같은 거 에스터 에그로 넣어 놔도 구글이 다 끄집어 낸다는 얘기 겠죠. 검색이 잘 되도록 하려면 SWFObject이나 Adobe detection code를 사용하라고 합니다.
