Google Adsense Side (160x600)



레티나 맥북프로와 앱 호환성에 대한 애플의 준비... 썩은 사과

기본적으로는, iOS때와 같은 방식이 사용된다고 할 수 있습니다.
그 방식이 무엇이냐...

iOS때는 이렇게 했습니다. 간단히 설명을 하면, 


1. 스크린 좌표계의 단위를 더 이상 pixel로 하지 않음

point라는 논리적인 단위로 하고, 모든 그와 관련된 기본적인 API들(화면에 뭔가 올리는것들)에 그 변경을 반영하는 방식을 사용했습니다. 그런 덕분에 기존의 pixel 단위를 가정하고 작성된 모든 기존 앱들도 시스템단(CoreAnimation에 근거한 compositing 엔진 혹은 WindowServer)에서 디스플레이 DPI 수준에 맞춰 픽셀좌표의 2배를 할지, 그냥 1:1로 매칭할지를 결정하므로 일반적인 앱에서는 별로 신경을 안써도 자동으로 물리적인 크기는 유지가 되도록 만들어 놓았습니다.

point * scaleFactor = pixel

레티나라면 저걸 조회하면 기본적으로 scaleFactor = 2 가 떨어지지만, 특정한 경우(특히 OpenGLES게임 등) 퍼포먼스등을 고려 1.5등의 비정수 배율을 사용하는 변태적인(?) 경우도 가능하답니다(WWDC 2010이던가? 처음 레티나가 등장했을때 설명에, 아무리 iPhone4가 성능이 뛰어나도(...--;) 3D 게임등에서는 1.5같은 비정수 배율의 프레임 버퍼로 렌더링 하고 최종 compositing시에 확대하는 방법을 써서 프레임을 올릴수도 있다...라고 했었죠).


2. 이미지 등의 리소스에 명명 규칙을 넣음

@2x 라는 suffix 를 가지는 이미지 리소스가 존재한다면, 일반적인 이미지 로딩 API들은 레티나 디스플레이상에서는 @2x가 붙은 놈들을 우선적으로 읽어들여 사용하게 됩니다. 일장일단은 있지만 애플스럽게 그냥 단순하달까 그런 느낌(안드로이드는 dpi별로 별도의 디렉토리를 쓰죠, 아마)...물론 자체적인 이미지 로딩 API를 구현했다면...--;


이래 놓으면 시스템의 API단에서 알아서 좌표 변경을 해서 compositing을 해 주고, 적절한 사이즈의 리소스를 읽어주고 하는 것입니다.
개발자나 사용자가 느끼기에는 큰 변화가 없죠. 아니, 화면 선명도만 올라가는 거죠.


여기까지의 설명이 아이폰4가 등장했던 2010년도에 벌어진 일입니다.


그러면 2011년에는 어떤 일이?

스물스물 iOS가 아닌 OSX에도 레티나의 기운이 밀려옵니다. 
OSX 10.7 Lion의 릴리즈 노트 중에 이런 녀석이 있었습니다.

High-Resolution Operation Release Notes

지금은 사이트에서는 내렸고, 개발자 문서에는 있네요. 2011년 6월 6일자 문서로 되어 있습니다, 
내용은 iOS때 했던 위에 언급한 그짓(?)과 다를 바 없는 내용이죠. 픽셀좌표가 아닌 point, 그리고 @2x의 고해상도 이미지 리소스.

그리고 다음과 같은 개발자 가이드 라인이 (원래 있었겠지만 대폭 수정되어) 등장했습니다(최종 수정일 2011년 5월 26일자 문서).

Introduction to Resolution Independence Guidelines

서두를 보면 고밀도 픽셀의 LCD가 나왔는데 pixel단위를 쓰면 버튼 따위가 깨알만해지는 병맛이 생길 것이라는 소리와 함께, 화면 해상도와 독립된 출력이 필요하답니다. 문서에 따르면 이미 10.4 타이거때도 준비는 했었는데 당시는 구현이 형편없었고, 이번에 10.7에서 제대로 지원되도록 refine했다고 합니다 - 이 refine은 아마도 iOS때 사용한 방법을 그대로 적용했다는 의미로 보입니다.

사실 전부터 Cocoa의 이미지 객체인 NSImage의 경우 size를 조회하는 경우 pixel 단위로 반환되지 않고 point단위로 반환해 왔습니다.
이걸 모르고 당연히 픽셀 단위라고 생각하면 엄청난 함정이 되기도 하죠. 대부분의 이미지는 72dpi라서 그걸 모르고 있다가, 한번이라도 그게 아닌 이미지가 들어오게 되면 뒤늦게 발견할 것입니다...즉, 있긴 있었지만 개발자를 불편하게만 했던 것이 아니었나 싶군요.
(iOS의 UIImage는 CGImage로 직결되어 있어 그런 일이 없지만, OSX의 NSImage는 안에 여러 dpi의 CGImage를 가질 수도 있음)


그리고 2012년...

그리고 2012년이 되어 정말로 HiDPI가 기본값인 디스플레이를 탑재한 맥이 나온 것이죠.
(그 사이에 모든 맥의 픽셀 해상도를 넘어서는 뉴 아이패드의 등장과, 1k * 1k 크기로 업그레이드된 아이콘 등의 준비가 있었던 것은 생략)

즉, OSX에서 레티나가 나와도 iOS에서 레티나 넘어갔던 때와 소프트웨어적인 접근방법은 거의 다를 바가 없으니,
기존 앱들의 버튼이 깨알만해지거나 하는 그런 문제가 일어날 가능성은 (거의) 없겠구나라는 점은,
애플 개발자나 사용자 입장에서는 놀라운 일이 아닌 것입니다.



그렇다고 기존 앱들이 전혀 호환성 문제가 없을까?


아쉽게도...그렇지는 않죠. Case by case가 될 것입니다.
앱의 특성, 구현 방식과 밀접한 관련이 있습니다.

point 좌표계가 적용되는 범위가 있는데, 바로 WindowServer나 그것의 기반이 되는 compositing 엔진인 Core Animation 입니다.
만일 그보다 저 레벨로 내려가면??

결정적인 문제는 OpenGL은 여전히 pixel 단위를 쓸 수 있다는 것이죠(논리적인 좌표 말고, 실제 프레임 버퍼).
별로 신기할 것은 아니에요. iOS때도 그랬거든요(퍼포먼스를 위해 1.5나 1.25의 비정수배율의 프레임버퍼사이즈를 가지고 렌더링 하는 것도 가능하죠-뭐 일반적인 것 같네요. 콘솔도 잘 그러죠).

특히 오프 스크린 버퍼(메모리나 텍스쳐)에 그리고, 그걸 단숨에 화면에 뿌리는 형태의 앱들, 그 중에 특히 pixel단위로 버퍼 크기를 정하고 그 버퍼에 렌더링하는 앱들...그런 앱들은 업데이트가 되어야 될 것입니다. 일례로 크롬이 있죠. 



물론 그런 경우라도 최종 Compositing 단계에서는 point로 변경이 되므로, 버튼 크기가 콩알만해지거나 글씨가 깨알만해지는 그런 문제를 겪을 가능성은 희박합니다. 다만, 레티나의 해상도 이득을 못보는 저해상도(?!) 컨텐츠를 보는 것 뿐이죠. 물론 대부분의 앱들의 경우 그런 구조일 가능성은 낮긴 합니다.

@2x 이미지 리소스가 준비가 안된 경우도 이런 상황이 벌어질 수 있습니다. 이런 경우는 상당히 많을 것 같네요. 
여전히 많은 앱들이 Snow Leopard를 최하 지원 OS로 삼고 있는 터라...
(그리고 수많은 iOS의 업데이트가 게으른 앱(...찔린다)들도 마찬가지)

굉장히 희박한 경우로 OpenGL 상에서 모든 것을 다 구현한 경우(블렌더...같은 경우 그런 것 같던데)는 어떻게 될지 궁금하네요. 뭐 그래도 일반적으로 조회 가능한 해상도 자체가 이미 포인트 단위라서 프레임 버퍼와 OpenGL View를 만들때 1:1의 2880*1800으로 만들어지지는 않을 것 같은데, 만일 만들어진다면, 그때는 정말 깨알같은 화면을 볼 수도 있겠죠.

물론 상기의 문제점 외에, 다른 부분에서 개발자의 실수로 인한 버그도 기대(?)됩니다. 오히려 이쪽이 치명적일 듯.

제가 최근에 뉴 아이패드의 레티나 디스플레이 덕분에 겪은 경험이 있습니다.
터치 좌표가 가리키는 이미지의 색상을 구해오는 코드였는데, 유독 레티나 디스플레이에서는 이상한 값이 반환되는 경우가 보고되었습니다. 상당한 삽질끝에 알아낸 것은, 의외로 간단한 이유였죠. (물론 이런 유형이 고치기는 참 어려운 버그가 아닐까 생각되지만)

offset = (int)(p.x * bytesPerPixel) + (int)p.y * bytesPerLine;

이 문제였는데...

offset = ((int)p.x * bytesPerPixel) + (int)p.y * bytesPerLine;

이랬어야 되는 것이라는 것을 발견하기까지 상당한 삽질을 요구했습니다.

터치 좌표(아마, 레티나에서의 마우스 좌표도 마찬가지일 것으로 생각됨. 포인팅 정확도를 포기하지는 않을 듯 하니)는 소수점 값을 가질 수 있죠. 거기에 round/floor/ceil이나 정수로 캐스팅이 들어갈 때 위와 같이 순서를 정확하게 하지 않은 경우 오차가 해괴하게 늘어나서 전혀 엉뚱한 값이 나오는 경우가 있습니다. 만일 p.x = 100.5 라면 반픽셀정도가 shift된 offset이 떨어지죠(즉 RGBA순서라면 BARG이런식으로 원래 픽셀의 반, 다음 픽셀의 반이 컴포넌트 순서도 얽힌채 읽힘). 
이런 버그가 있는 앱이라면 당연히 이상 행동을 할 수 있으며, 이는 전적으로 개발자의 실수이므로, 해당 개발자가 수정해야되는 문제이고, 애플이 해결해 주기는 어려운 문제겠죠.


결론

그래서 제가 내릴 수 있는 결론은:

애플은 이미 iOS에서 적어도 2년간 테스트, 및 개발자 교육을 통해 차근차근 준비를 해 온 바, 고밀도, 고해상도 디스플레이에서도 기존 앱들의 호환성 문제를 최소화 하는 방식으로 이전할 준비가 되어 있었다.

하지만, 개별 앱이 100% 레티나 대응이 되는 것은 아닐 것이다. 그래도 저해상도로는 보일지언정, 사용상에 불편을 초래하는 레이아웃 깨짐이나 깨알같아지는 UI같은 문제는 거의 발생되지 않을 것이다.

입니다. 물론 부트캠프 상황에서는 전혀 보장할 수 없는데...예측은 디스플레이 드라이버 차원에서 저해상도를 지원해 주지 않을까요? 
다만 선명도는 많이 깎이고 시작하니 그냥 윈도 PC를 하나 더 지르는 것이 현명하다고 생각됩니다.


그 외 개인적인 잡상:

처음에 이번에 비정수배율을 지원해 줄 것인가? 가 궁금했습니다.
그런데, 결과적으로 지원은 지원이지만...애플의 접근 방법은 이랬군요. 
Anandtech의 스크린샷을 보면 다음과 같은 것 같습니다.

무조건 2배율의 프레임버퍼(looks like 1920*1200이라면 3840px*2400px)에다가 렌더링을 합니다(당연히 1point=2pixel). 
그리고 그걸 보다 저해상도(!)인 2880*1800으로 다운샘플링하는 것입니다. 

마치 콘솔게임이나 OpenGL게임등에서 보다 저해상도로 렌더링 하고 그걸 고해상도 화면에 매핑하는 것과 반대로...아, 이거 그냥 Supersamping Full Scene Anti-aliasing 인가요? 

애플다운 미친짓의 하나로 보입니다만, 그렇게 해서 선명도가 깎이는 것을 최소화 하겠다는 의지가 보입니다.
그리고 좀더 확장해 보면, 향후 오리지널 모델과 다른 배율의 해상도를 가진 iOS기기가 등장하는 경우도 비슷한 짓을 할 것 같네요.

화면 중간에 걸친 윈도의 경우는?
어차피 스크린샷 떠 보면, OSX의 경우 제가 기억하는 윈도와는 다르게(윈도는 하나의 커다란 파일로 캡쳐되었었음) 디스플레이별로 프레임버퍼가 따로 들어가는 구조로 보입니다. 지금 저처럼 모니터 3개 돌리는 경우 파일도 3개가 나옵니다. 따라서 이 역시 아무런 문제가 없어보이고, 레티나 맥북 프로보다 빨리 HiDPI를 지원했던 Air Display인가 하는 앱(뉴 아이패드를 모니터로 쓰도록 해주는 앱)을 돌리는 영상을 봐도 그런 문제가 없더군요.

그리고 가격도...솔직히 비싸지는 않게 느껴집니다.
맥북 프로가 원래 그 가격이었고(Core2Duo 2008년 모델, 메모리도 겨우 2GB달고 나왔던 제 최초의 맥북 프로가 그가격부터 시작했었죠), 성능이 사실 대폭 올랐기 때문에 가격이 유지된 것만 해도 상당히 억제된 가격으로 보입니다. 기본으로 SSD(물론 커스텀이라...--;)를 탑재했는데, 그걸 CTO해 보면 맥북 프로 치고는 쌉(?)니다.
현재는 딱히 비교할 수 있는 경쟁 모델도 없고...또한 당분간 없을 것 같은데, 애플식으로 거의 모든 부품을 커스텀으로 발주할 수 있는 업체가 없으며 HiDPI 준비가 되어 있는 경쟁 OS도 아직...

그러니 애플에서 개발하고놀아보고 싶다면 질러볼만한 물건이라고 생각됩니다.

어차피 위에 언급한 제 개인 맥도 사망했고, 회사에서는 이런저런 태클로 OS를 언제까지 업그레이드 하지 말라고 하고 그러니, 총알만 장전되면 바로 지르기로 결심했습니다.
(다만 이미 지출 큐가 꽉 차서 언제가 될지는 미지수...--;)