HiDPI

2013년 Windows 8.1부터 도입된 Microsoft Windows 기반 컴퓨터 디스플레이의 몇 배 더 많아진 픽셀 수만큼 몇 배로 더 선명하게 보여주는 표시 방식.

2000년대까지는 수많은 디지털 기기들이 화면에 대한 큰 욕심을 내지 않았다. 그저 '글씨를 보여 줄 수만 있는' 최소한의 낮은 해상도를 사용해왔던 것이다. 초창기 피처폰과 같은 경우도, 176*220(QCIF+)[1]이나 240*320(QVGA) 등의 낮은 해상도에서 문자를 사용자에게 보여주어서 편의적으로도, 심미적으로도 심각하게 좋지 못한 사용자 경험을 남겼다.[2]

2018년 기준, 플래그쉽 스마트폰의 주력 해상도 WQHD(2560x1440)[3]는 PC 모니터에 가장 많이 쓰이는 해상도인 FHD(1920*1080)보다 더 높아졌다. 예외도 있긴 하지만 일반적인 스마트폰보다 일반적인 모니터가 화면에 들어간 점의 개수가 더 줄어들었다. 모니터는 큼직하고, 스마트폰은 손 안에 들어갈 정도로 작은데도 말이다. 1인치의 길이에 들어가는 픽셀의 개수를 PPI(Pixels Per Inch)라는 단위로 표기하는데 당연히 PPI 값은 스마트폰이 모니터보다 월등히 높다. 픽셀이 화면에 훨씬 빽빽히 모여 있으므로, 스마트폰에서는 모니터보다 훨씬 더 선명하게 문자를 나타낼 수 있다.

피쳐폰에서 스마트폰으로 넘어오는 과도기에는 스마트폰도 PPI 및 해상도가 지금보다는 훨씬 낮았고, 특히 480*800 해상도를 가진 4인치대 디스플레이[4]가 많이 쓰였었다. 그러다 2010년대 들어, PPI에 따른 화면의 선명함이 디스플레이의 중요한 미덕으로 떠오르기 시작했다.

이와 같은 스마트폰 디스플레이의 PPI 부문의 품질 경쟁을 촉발한 것은 Apple이 2010년에 출시한 iPhone 4였다. 이 때 쓰인 Retina 디스플레이라는 용어는 300 PPI 이상의 화면을 가리키는 말이었고, 실제로 그 선명도는 326 PPI에 달해 당시 다른 스마트폰과 비교가 되지 않는 깔끔하고 선명한 디스플레이의 아름다움을 보여주었다. 이를 기점으로 출시되는 대다수의 스마트폰이 300PPI는 '당연히' 넘겨야 하는 기준선으로 삼기 시작했고, 엑스페리아 XZP의 경우에는 806 PPI라는 엄청난 선명도를 가진 디스플레이를 담고 나왔다. 참고로, 레티나 디스플레이라는 용어의 정의는 다소 모호해진 상태이다.

이런 고밀도 디스플레이를 컴퓨터 계열에서 보급한 것 역시 애플이었다.[5] 맥북에도 3K(2880x1800) 레티나 디스플레이를 탑재하면서 처음으로 컴퓨터 화면을 선명하고 보기 좋게 만드는 데에 성공한 것이다. 또한 운영체제 UI 전체에 안티에일리어싱을 걸어버리는 Apple macOS의 서체 렌더링을 통해 이러한 장점은 더욱 부각되었다. 운영체제와 하드웨어를 동시에 제작하는 Apple이었기에 가능한 일이었고, 이 부분에서는 Apple이 현재까지도 우위를 점하고 있다. 27형 iMac에는 무려 5.33K(5120x2880) 해상도의 Retina 5K 디스플레이를 탑재하면서 일체형 PC 계열에서도 Retina 디스플레이가 탑재되었다.

그러나 Windows PC, 특히 Windows 8 이전 버전에서는 아직도 초창기 피처폰 수준과 비슷한 선명도로 화면을 띄우고 있다. 물론 컴퓨터 디스플레이는 스마트폰보다 먼 곳에서 보기 때문에 선명도가 좀 떨어지더라도 큰 지장은 없지만, 시야 거리를 고려하더라도 컴퓨터가 스마트폰에 비할 때 해상도가 너무 낮은 것은 사실이다. 이러한 원인 중에는 PC의 많은 기능이 스마트폰으로 내려오면서 PC에 소홀했던 점도 있다.

Windows가 운영체제 단에서 삼고 있는 기준은 96 PPI[6]밖에 되지 않는다. 이것은 Windows 7 또는 이전 버전을 애플 MacBook Pro에 Boot Camp로 설치할 경우 실감할 수 있다. 작업 표시줄 등 여러가지가 굉장히 작게 보인다. 9x 계열의 윈도우들 역시 화면 DPI 설정 기능 자체는 있었으나, 이 때의 DPI 설정 기능은 아예 96 DPI보다 더 낮은 해상도를 사용 할 것으로 가정하고 개발했던 것이라서 Windows 8.1 부터 지원되기 시작한 HiDPI 지원과는 거리가 굉장히 멀었다. 당시에는 고해상도 디스플레이가 상용화되지 않았기 때문에 9x 계열의 윈도우 에서 창을 최소화시키면 3000, 3000 좌표[7]에 창을 배치시켰다. NT 계열의 윈도우들과 GUI 스택 구조가 근본적으로 다른 탓에 화면 해상도를 높이면 Windows의 중요 모듈인 GDI, USER 등이 사용하는 힙(heap) 공간을 의미하는 리소스를 조금이나마 깎아먹기 때문에 해상도를 높게 잡기가 굉장히 부담스럽기 까지 했다.[8]

2013년 Windows 8.1 이후 본격적으로 고해상도 디스플레이를 위한 HiDPI를 지원하기 시작하면서, 상술된 문제들이 점차 해결되고 있다.

High DPI를 줄인 말로, High와 발음이 거의 같은 Hi로 바꾸고 DPI를 붙여서 HiDPI라는 단어로 압축하였다.

윈도우는 레거시 프로그램과 하위 호환을 어떻게든 끌고 가려는 끈질긴 운영체제다. 출시된 지 20년이 지난 옛날 게임인 스타크래프트가 공식적으로 최신 윈도우를 지원하게 된 1.18 패치 이전에도 Windows 10으로 돌아갈 수 있었던 이유도 MS가 호환성을 유지하려고 부단히 노력한 덕택이다. 그러나 옛날 프로그램을 돌리는 것은 해낼지라도, 고해상도의 고밀도 디스플레이에서 적절한 배율로 늘려 제대로 된 크기로 나타내는 것에는 어려움이 있다. HiDPI 지원이 뛰어난 macOS의 경우에는 커널을 여러 번 갈아엎으면서 레거시 프로그램의 호환성을 끊어버려 HiDPI를 제대로 지원하는 프로그램이 대다수가 되었기 때문에 큰 문제가 없는 것이다. 특히 Windows의 레거시 지원은 어떠한 기능이 폐기(Deprecated) 되더라도 macOS나 Linux처럼 컴파일시 경고를 띄우거나 아예 오류가 나는 것이 아니라 그대로 사용이 가능하기 때문에 이런 신기능에 대한 학습이 없는 프로그래머들이 옛날 방식을 그대로 사용하게 되는 문제가 있어 2020년 현재에도 HiDPI 지원이 엉망인 프로그램들이 여전히 존재한다.

화면 속에서, 원래는 a*b 크기인 오브젝트를 na*nb 크기로 키우는 것을 '스케일링(Scaling)'이라고 한다. WIndows의 기본값은 100%(96 PPI)이며, 화면 크기보다 해상도가 높은 경우에 화면에 표시되는 프로그램 및 아이콘 등의 오브젝트들이 작게 표시되는데, 이를 n배로 확대시켜 보기 편하게 하는 것이 바로 HiDPI이다. 참고로 n에는 자연수[9]가 들어가야만 계단이나 자글거림이 발생하지 않으며, 소수[10]가 들어가면 비교적 덜 깔끔해진다. 물론 사람에 따라 불편함을 느끼지 않는 경우도 많으니, 직접 눈으로 확인해 보며 조절하는 것이 가장 좋다.

소위 '프로그램이 깨져 보인다'는 부작용이 일어나기도 하는데, 아주 먼 옛날 프로그램은 의외로 크게 문제를 보이지 않고 오히려 10년 전 정도의 근래의 프로그램에서 자주 발생한다. 아주 먼 옛날 프로그램은 이런 고해상도를 염두에 두지 않고 개발했기 때문에 OS에서 강제로 확대하면 끝이지만, HiDPI 지원의 과도기적인 근래의 프로그램의 경우 HiDPI가 어중간하게 지원하여서 오히려 이상하게 표시된다. 그러는 경우에 버튼이 어딘가로 튀어나가 있거나 글자가 상자를 뚫고 나오기도 한다. 비교적 최신 소프트웨어들에서는 HiDPI 관련 문제가 적은 편이다.

윈도우로 작동하는 프로그램은 HiDPI를 지원하는 걸 세 가지로 분류할 수 있다. 'HiDPI를 제대로 지원하는 것', '어중간한 것', '아예 지원하지 못하는 것'. 이 가운데에서 어중간하게 지원하는 것이 보통 문제가 된다.

HiDPI를 제대로 지원하는 경우 프로그램은 Windows의 배율 설정을 제대로 알고 표시하기 때문에 문제가 발생하지 않는다. 아예 지원하지 않는 프로그램의 경우 윈도우에서 배율만큼 크게 표시한다. 단, 강제로 확대해서 표시하는 것이기 때문에 글자가 흐려진다. 또한 카탈리나부터 32비트 API인 카본이 삭제되면서 의미가 없어졌긴 했지만 macOS도 HiDPI를 지원하지 않는 앱의 경우 강제로 윈도우와 같이 확대해서 표시되어 카본이 살아있던 시기에는 윈도우처럼 흐릿하게 표시되는 프로그램들이 여럿 있었다.

여기서 크게 문제가 되는 어중간하게 지원하는 경우이며, 위에서 설명했지만 사람들이 자주 사용하는 근래의 프로그램이 대개 해당된다. '확대가 안 되는 것', '뭔가 제대로 꼬인 것'으로 다시 분류할 수 있다. 어중간하게 지원하는 프로그램의 경우 후술할 호환성 설정법으로 강제 확대할 수 있다.

확대가 안 되는 것은 배율설정을 무시하고 무조건 픽셀에 1:1 매칭되어 표시되는 프로그램으로, 시스템 비율이 200%(192 DPI)로 맞춰져 있더라도 프로그램은 무조건 100%(96 DPI)로 표시되기 때문에 정상적인 사용을 못 한다.

뭔가 제대로 꼬인 것 같은 프로그램은 개발툴[11]이 HiDPI를 제대로 지원하지 않았거나[12], 지원은 하지만 같이 사용한 서드파티 툴이 지원이 안 돼서 섞여 있거나, 개발자가 무시하고 개발하면 발생한다. 현재로서는 시간이 흘러 윈도우에서도 HiDPI 앱이 대세가 되기를 기다리는 수밖에 없다.

HiDPI를 제대로 지원하는 프로그램의 경우 실제 해상도가 더 높기에 더 깔끔하고 자연스럽게 표시된다. 아직은 HiDPI를 사용할 만한 초고해상도 디스플레이가 점유율을 차지한 지 얼마 되지 않았지만, 시간이 지나면서 초고해상도 화면을 가진 기기들이 눈에 띄게 늘어나고 있다. 삼성 노트북 9 프로나 델 XPS 15가 대표적이다. 와콤도 신티크 최신판, 모바일스튜디오 프로에서 4K를 지원하기 시작했다. 물론 이들의 가격은 MacBook Pro와 비슷하다는 게 함정이다.

Windows 10부터는 HiDPI 지원을 위하는 Awareness 단계가 나누어져 있다.

불완전하게 지원하는 것은 △ 표시.

실행하려는 앱 파일을 우클릭한 뒤, 속성의 호환성 탭에서 "높은 DPI 동작을 재정의합니다."를 체크하고 '시스템'[25] 또는 '시스템(고급)'[26][27]을 선택하면 된다.

윈도우 10 빌드 15063 이전의 구 버전은 이 방법을 사용해야 한다.

클리어타입 대체용으로 만들어진 글꼴 렌더링 프로그램인 MacType이 있는데, HiDPI 환경에서 사용하면 글꼴이 상당히 매끄러워져서 보기가 편안해진다. 다만 커널 후킹 방식으로 동작하기 때문에 호환성 문제가 발생할 수 있다.

데스크탑 리눅스의 경우 X11또는 Wayland 디스플레이 서버 위에서 GTK, Qt와 같은 UI 툴킷이 돌아가는 구조이다.

디스플레이 서버의 경우 구식 디자인의 X11보다는 Wayland가 더 현대 데스크탑에 맞게 설계되어 있다 보니 HiDPI를 더 잘 지원하고 있고, UI 툴킷의 경우 그에 맞추어 대표적으로 사용되는 GTK나 Qt 또한 디스플레이 서버의 HiDPI 프로토콜을 잘 지원하고 있기 때문에 오래된 툴킷을 사용하는 데스크탑 배포판 환경이 아닌 이상 (GTK2, Qt4 등) 어지간하면 다 지원하는 편이다

그리고 최종적으로 사용자가 보는 환경은 GNOME, KDE, XFCE, LXDE 등등으로 나뉘게 되는데 이 데스크탑 환경의 지원 수준에 따라 지원 실정이 다르다. HiDPI를 제대로 지원하는 데스크탑 환경도 있고, 그렇지 않은 환경도 있기에[28] 일단 제대로 지원하는 환경이기만 한다면 윈도우보다는 훨씬 사정이 낫다.

대표적으로 사용되는 데스크탑 환경 중 하나인 그놈은 최신 3.30 버전에서 2의 배수 단위로 스케일링을 지원하고 있다. 차후 윈도우와 비슷하게 공식적으로 125%, 150% 등의 세부 단위를 지원할 예정. GNOME Tweak Tool을 사용자가 직접 설치하여 스케일 상수를 바꿔주면 바로 사용할 수 있다. 정식 지원 기능이 아님에도 오히려 윈도우보다 더 잘 작동한다는게 아이러니하다.

Windows와 비교했을때 리눅스의 장점으로는 윈도우처럼 HiDPI 과도기 프로그램 때문에 깨져보이는 프로그램은 상대적으로 적고[29] 글꼴 렌더링이 클리어타입이 아닌 macOS와 비슷한 FreeType을 사용하고 있으므로 고해상도에서 글자가 선명해보인다. 또한 굴림과 돋움 글꼴이 없기 때문에 상대적으로 웹페이지가 깨끗하게 보인다.

다중 모니터는 Wayland에서만 제대로 된 스케일링을 지원한다. Xorg에서도 xrandr을 사용하면 모니터마다 스케일링을 할 수 있지만, 일부 엔비디아 GPU에서 작동하지 않거나 화면이 깨지는 등 버그가 발생할 수 있으니 주의.