최근 수정 시각 : 2024-10-16 20:59:45

HiDPI

하이디피아이에서 넘어옴
1. 개요2. 역사
2.1. 휴대폰2.2. 컴퓨터
3. 운영 체제의 HiDPI 지원
3.1. Microsoft Windows
3.1.1. HiDPI를 지원하는 주요 소프트웨어 목록3.1.2. HiDPI를 제대로 지원하지 못하는 소프트웨어의 해결책3.1.3. 기타
3.2. macOS3.3. 리눅스
4. 웹 브라우저의 HiDPI 지원
파일:tm_1409eizo_02.jpg
파일:tm_1412_ppi_07_8.jpg
DPI 차이를 이미지로 설명한 예시 UHD 4K (좌)와 Full HD (우) 실제 비교 사진

1. 개요

컴퓨터 디스플레이의 몇 배 더 많아진 픽셀 수만큼 몇 배로 더 픽셀을 사용[1] 하여 선명하게 보여주는 표시 방식.

대표적으로 Apple에서는 Retina 디스플레이와 함께, Microsoft Windows에서는 2013년 Windows 8.1부터 본격적으로 도입되었다.

2021년 기준으로는 Display Scaling(화면 배율)이라는 용어가 더 많이 보인다.
파일:1920-x-1080-normal.jpg 파일:3840-x-2160-normal.jpg
FHD 해상도 4K 해상도
4K 해상도에서 일반적으로 쓰여왔던 100%(96DPI)를 적용할 경우 바탕화면 아이콘부터 작업 표시줄 등 모든 UI가 상당히 작아져버린 것을 알 수 있다

거꾸로 보자면 일반적인 사용자나 OS 설정 차원의 시각에서 디스플레이가 초고밀도화 된 만큼 화면의 객체들이 보통의 픽셀만큼(종래 보편적인 100% 96DPI 등)만 사용해서 표시하게 되면 사용자에 따라 화면이 알아보지 못할 정도로 굉장히 작아져버릴 수 (화면 크기는 동일하지만 해상도가 커짐) 있는데 이를 일반적인 디스플레이에서 보아왔던 통상 수준의 크기로 보일 수 있도록 배율(DPI)을 키워주는 (즉 같은 객체를 표시하는 데 있어 더 많은 픽셀을 사용하며 종래의 해상도만큼 해상도가 다시 줄어드는 효과) 것의 의미로 (즉 HiDPI 지원 등의 의미) 받아들여지기도 한다. 다만 해상도 자체를 줄여버리면 LCD 특성 상 픽셀매칭이 되지 않아 화면이 뿌얘져 버리는 반면에 해상도는 그대로 두고 DPI 조절을 통해 배율을 높이면 본연의 해상도(예를들어 4K 동영상 등)와 선명함(특히 글자 폰트 등)을 유지하면서도 화면을 크게 볼 수 있게 된다. 쉽게 보면 웹 브라우저에서 확대 시에도 폰트 글자가 뿌얘지진 않는 것을 예로 들 수 있겠다. 이러한 것이 OS UI 차원에서 전체적으로 적용되는 것이라 할 수 있다.

2. 역사

2.1. 휴대폰

2000년대까지는 LCD 기술이 부족해 '글씨를 볼 수만 있는' 최소한의 낮은 해상도를 사용해왔다. 초창기 피처폰과 같은 경우도, 176×220(QCIF+)[2]이나 240×320(QVGA) 등의 낮은 해상도에서 문자를 사용자에게 보여줘도 만족하는 사람들이 많았다. 이 당시에는 휴대폰이라는 개념이 단지 전화, 문자만 주고받는 수준이었기에 240×320(QVGA)도 고해상도로 취급되었다.[3]

피처폰에서 스마트폰으로 넘어오는 과도기에도 스마트폰은 PPI 및 해상도가 지금보다는 훨씬 낮았고, 특히 480×800 해상도를 가진 4인치대 디스플레이[4]가 많이 쓰였었다.

그러다 2010년대 들어, PPI를 늘려 화면을 선명하게 하는 것이 디스플레이 장치의 중요한 미덕으로 떠오르기 시작했다. 이같은 스마트폰 디스플레이 장치의 PPI 경쟁을 촉발한 것은 Apple이 2010년에 출시한 iPhone 4였다. 이 때 쓰인 Retina 디스플레이라는 용어는 300 PPI 이상의 화면을 가리키는 말이었고, 실제로 그 선명도는 326 PPI에 달해 당시 다른 스마트폰과 비교가 되지 않는 깔끔하고 선명한 디스플레이의 아름다움을 보여주었다. 이를 기점으로 출시되는 대다수의 스마트폰이 300 PPI는 '당연히' 넘겨야 하는 기준선으로 삼기 시작했고, 엑스페리아 XZP의 경우에는 806 PPI라는 엄청난 선명도를 가진 디스플레이를 담고 나왔다. 참고로, 레티나 디스플레이라는 용어는 이제 애플만 마케팅 목적으로 사용하고 있다.

2.2. 컴퓨터

컴퓨터에 고밀도 디스플레이를 본격적으로 도입하기 시작한 것 역시 애플이었다.[5] 2012년 맥북 프로에도 3K(2880×1800) 레티나 디스플레이를 탑재하면서 처음으로 컴퓨터 화면을 선명하고 보기 좋게 만드는 데에 성공한 것이다. 또한 운영 체제 UI 전체에 안티에일리어싱을 거는 Apple macOS의 서체 렌더링과 응용 프로그램까지 서체 디자인 일관성을 맞추면서 이러한 장점은 더욱 부각되었다. 운영 체제와 하드웨어를 같이 만들고 있는 Apple이었기에 가능한 일이었고, 이 부분에서는 Apple이 현재까지도 우위를 점하고 있다. 27형 iMac에는 무려 5K(5120×2880) 해상도, 218 PPI의 Retina 5K 디스플레이를 탑재하면서 일체형 PC에도 Retina 디스플레이가 탑재되었다.

Windows의 글꼴 크기 기본값은 3.x까지 72PPI[6], 이후 96 PPI(100%)였다. Windows 9x들도 DPI 설정 기능은 있었으나, 더 낮은 해상도의 모니터를 기준으로 만들어졌기 때문에 96 PPI보다 더 낮은 값만 설정할 수 있는 수준이었다. Windows 9x는 창을 최소화시키면 가로, 세로 3000, 3000 위치의 좌표[7]에 창을 배치시켰다. NT 커널 Windows들은 GUI 스택 구조가 근본적으로 다른 탓에 화면 해상도를 높이면 Windows의 중요 모듈인 GDI, USER 등이 사용하는 힙(heap) 공간을 의미하는 리소스를 조금이나마 깎아먹기 때문에 해상도를 높게 잡기가 굉장히 부담스러웠다.[8]

Windows XP부터 높은 DPI로 조절할 수 있는 기능이 제공되기 시작했다. 그때에는 단지 필요성이 적어 운영 체제 스스로를 제외하면 외부 프로그램이 잘 지원하지도 않았고 운영 체제에 그 기능이 있었는지 몰랐을 뿐이었다. 당시 컴퓨터 이용자 대다수는 FHD 해상도가 겨우 표준으로 막 자리잡고 디스플레이가 한창 널리 보급되는 중이었던 상황이었기 때문에 높은 PPI가 요구되지 않았다. FHD 해상도를 넘어선 고해상도의 모니터는 가격이 상당히 비쌌기 때문에 전문가 장비로 취급되었다. 물론 컴퓨터 디스플레이는 스마트폰보다 먼 곳에서 보기 때문에 PPI가 좀 떨어지더라도 큰 지장이 없었던 점도 있었을 것이다.

그러다 지상파 방송, 촬영 장비, 유튜브, 스트리밍 서비스 및 그 외 각종 콘텐츠들이 무수히 쏟아지면서 PC도 4K UHD 디스플레이가 보급되기 시작했다. 이에 따라 이러한 고해상도 이용자들을 위해 HiDPI에 대응할 필요성 또한 높아지게 되면서 Windows도 HiDPI 지원 기능을 더 개선했다. Windows 7에서는 DPI 설정에서 100%(작게), 125%(중간), 150%(크게) 등의 옵션 제공 및 디스플레이의 크기와 해상도를 파악하여 상황에 따라 자동으로 125% 옵션을 기본값(자동)으로 삼는 등 기능을 보다 강화하였다.[9] 여담으로 동사의 Microsoft Office 또한 이미 2010 버전부터 HiDPI 대응이 어느정도 이루어졌다.

그리고, 2013년 Windows 8.1( 2012 R2)부터 더 개선되어 고정된 수치의 DPI 배율 설정이 아닌, '작게-보통-크게'의 개념으로 설정할 수 있도록 발전하였고, 이에 따라 컴퓨터에 연결된 여러개의 각 모니터마다 상황에 맞는 각기 다른 가변적 DPI가 한 세션 내에서 사용될 수 있게 되었다. 이렇게 본격적으로 고해상도 디스플레이를 위한 HiDPI를 지원하기 시작하면서, 상술된 문제들이 점차 해결되고 있다.

일부 "해상도 == 작업공간" 으로 인식하고 있는 사람들의 경우 HiDPI 무용론을 주장하는 경우가 있는데 HiDPI는 UI의 요소만 특정 해상도에 맞게 스케일링 할 뿐 컨텐츠 자체는 원본 해상도 그대로다. 예를 들어 4K 27인치의 화면을 200%로 스케일링 해서 사용하는 경우 실제 해상도는 UHD이지만 UI요소만 FHD처럼 표시되는 것으로 컨텐츠의 내용은 4K해상도 그대로지 FHD로 표시되는 것이 아니다.

3. 운영 체제의 HiDPI 지원

3.1. Microsoft Windows

윈도우는 레거시 프로그램을 위한 하위 호환을 어떻게든 끌고 가려는 끈질긴 운영체제이다 보니 출시된지 20년이 지난 옛날 게임인 스타크래프트가 공식적으로 최신 윈도우를 지원하게 된 1.18 패치 이전에도 Windows 10으로 돌아갈 수 있었던 이유도 MS가 호환성을 유지하려고 부단히 노력한 덕택이다.

옛날 프로그램을 돌리는 것은 해낼지라도, 고해상도의 고밀도 디스플레이에서 적절한 배율로 늘려 제대로 된 크기로 나타내는 것에는 어려움이 있다.

HiDPI 지원이 뛰어난 macOS의 경우에는 커널을 여러 번 갈아엎으면서 레거시 프로그램의 호환성을 끊어버려 HiDPI를 제대로 지원하는 프로그램이 대다수가 되었기 때문에 큰 문제가 없는 것이다. 특히 Windows의 레거시 지원은 어떠한 기능이 폐기(Deprecated) 되더라도 macOS나 Linux처럼 컴파일시 경고를 띄우거나 아예 오류가 나는 것이 아니라 그대로 사용이 가능하기 때문에 이런 신기능에 대한 학습이 없는 프로그래머들이 옛날 방식을 그대로 사용하게 되는 문제가 있다. 2020년 현재에도 HiDPI 지원이 엉망인 프로그램들이 여전히 존재하다 보니 사실상 Windows의 HiDPI 지원 문제는 과거 기술에 안주하는 업데이트가 게으른 프로그램들의 문제라고 봐도 무방한데, Windows는 HiDPI 관련 API를 Windows 8.1부터 제공하고 있기 때문이다.

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

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

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

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

여기서 크게 문제가 되는 어중간하게 지원하는 경우이다. '확대가 안 되는 것', '뭔가 제대로 꼬인 것'으로 다시 분류할 수 있다. 어중간하게 지원하는 프로그램의 경우 후술할 호환성 설정법으로 강제 확대할 수 있다.

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

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

HiDPI를 제대로 지원하는 프로그램의 경우 실제 해상도가 더 높기에 더 깔끔하고 자연스럽게 표시된다. 아직은 HiDPI를 사용할 만한 초고해상도 디스플레이가 점유율을 차지한 지 얼마 되지 않았지만, 시간이 지나면서 초고해상도 화면을 가진 기기들이 눈에 띄게 늘어나고 있다. 삼성 노트북 9 프로나 델 XPS 15가 대표적이다. 와콤도 신티크 최신판, 모바일스튜디오 프로에서 4K를 지원하기 시작했다. 물론 이들의 가격은 MacBook Pro와 비슷하다는 게 함정이다.
파일:KoreanGlyphsInHIDPI.webp
스케일링에 따른 글꼴 표현 차이
상위 3개는 각기 굴림, 돋움, 바탕이며 100% 에서는 비트맵 글꼴 특성상 칼같은 가독성을 보여주지만 100%를 벗어나는 순간 글꼴의 굵기가 얇아지며 가독성이 저하된다.

웹 브라우저같이 독립적인 좌표계를 사용하는 프로그램은 별 문제가 없을 것 같지만 웹사이트의 CSS의 font-family에 굴림이나 돋움같이 크기가 커질수록 모양이 변하고 얇아지는 글꼴을 넣어두는 사이트들 때문에 Windows는 맥에 비해 HiDPI지원이 안 좋다라는 인식을 주고 있다. HiDPI 적용시 미려하게 나오는 맑은 고딕, 나눔고딕, 본고딕이 있지만 아직 사용률은 낮다.

Windows 10부터는 HiDPI 지원을 위하는 Awareness 단계가 나누어져 있다.
  • 지원하지 않음: 모든 환경에서 96DPI로 고정된다. Windows 8.1 부터 이 환경에서는 비트맵 스케일링을 하기 때문에 비 정수배 스케일링 환경에서 흐릿하게 보이는 효과를 가져온다.
  • System DPI Aware: Windows Vista 부터 지원한 방식. 주 모니터의 DPI를 설정을 모든 곳에서 사용한다. 이 때문에 모니터를 한대만 사용하거나 멀티 모니터여도 모니터간의 DPI가 동일하다면 HiDPI를 잘 지원하는 것으로 보이나, 주 모니터의 DPI만을 사용하게 되어서 시스템에 여러개의 각기 다른 DPI를 가진 모니터가 설치된 환경에서 모니터간 창을 이동하여도 창의 DPI가 변경되지 않는 문제점이 있는데 Windows 10 부터는 비트맵 스케일링을 하지만 근본적으로 네이티브 스케일링이 적용되지 않아 흐릿하게 보이게 된다. (e.g: 4K 200% → FHD 100%)
  • GDI Upscale: Windows 10 1703 RS2 부터 지원된 방식. 기본적으로 100% (96DPI)로 고정되나, GDI 부분을 내부적으로 스케일링하여 렌더링한다. DPI Awareness가 없고 GDI를 사용하는 레거시 프로그램들을 위한 과도기적 방법이기 때문에 OpenGL이나 DirectWrite와 같은 컴포넌트를 사용하는 부분은 스케일링을 지원하지 않는다.
  • Per-Monitor: Windows 8.1부터 지원되기 시작한 HiDPI 지원. 이 방식은 창이 있는 모니터별로 창의 스케일링이 변경될 수 있음을 알린다.[13] 즉 200%로 스케일된 4K모니터와 100% 스케일을 사용하는 FHD모니터가 시스템에 설치되어 있는 경우, 4K 200%에서는 192 DPI로 스케일링되고 표시되며, FHD 100%에서는 96 DPI로 다시 렌더링되어서 가장 이상적인 환경을 볼 수 있다. Chrome이 이를 지원하는 대표적인 예이다.
    내부적으로 Per-Monitor V1과 Windows 10 1703 부터 지원된 Per-Monitor V2가 있는데, V1은 모니터간 DPI 변경을 감지하지만 모든 디스플레이의 좌표에 실제값을 사용해서 그에 맞춰 직접 스케일링해야 하는 것에 비해 V2의 경우 좌표 가상화를 지원한다.

3.1.1. HiDPI를 지원하는 주요 소프트웨어 목록

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

3.1.2. HiDPI를 제대로 지원하지 못하는 소프트웨어의 해결책

실행하려는 앱 파일을 우클릭한 뒤, 속성의 호환성 탭에서 "높은 DPI 동작을 재정의합니다."를 체크하고 '응용 프로그램' 또는 '시스템(고급)'[25][26]을 선택하면 된다. 보통은 응용 프로그램과 시스템(고급) 중 하나는 효과를 볼 수 있고, '시스템'은 효과가 없다고 봐도 된다.

각 옵션에 따른 적용되는 HiDPI 모드는 다음과 같다:
  • 응용 프로그램 (Application) - HiDPI 스케일 옵션을 전적으로 프로그램에게 맡긴다. 게임들과 같이 별도의 프레임버퍼를 사용하는 프로그램들의 경우 OS의 스케일링이 필요하지 않음에도 불구하고 프로그램이 HiDPI를 지원한다는 메타데이터가 누락 된 경우 4K에서 200% 스케일을 사용하는 경우 게임 렌더링이 FHD로 되는 문제가 있는데 해당 옵션을 선택하면 정상적으로 사용이 가능하다. Per-Monitor V2 상태와 동일하다.
  • 시스템 (System) - 비트맵 스케일링. HiDPI를 지원하지 않는 프로그램이 HiDPI를 지원한다는 메타데이터를 가지고 있거나 Per-Monitor에 대한 지원이 없음에도 지원한다고 선언되어 있는 등 잘못 만들어진 프로그램들의 HiDPI 스케일링을 막고 시스템이 직접 스케일링한다. 이 경우는 Unaware 모드로 동작하는것과 동일하다. 다만 런타임 환경에서 HiDPI 옵션을 불러오는 (Qt 5.4 이하의 라이브러리로 만들어진 프로그램들이 대체로 해당) 경우에는 해당 옵션이 무시되는 경우가 있으며 이 경우는 Manifest를 직접 수정하여야 한다.
  • 시스템 (고급) (System (Enhanced)) - GDI Upscale 을 한다. 즉 GDI로 렌더링이 진행되는 레거시 프로그램들에게서 효과가 있는데 내부적으로 스케일을 하고 나머지는 Unaware 모드로 둔다. 그래픽은 어쩔수 없지만 GDI와 같이 UI의 텍스트 부분은 선명하게 렌더링 된다. 다만 내부적으로 Direct2D, DirectWrite, Direct3D 등과 같은 모던 API로 그래픽을 그리는 경우 역효과가 생기므로 주의.

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

3.1.3. 기타

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

3.2. macOS

macOS는 확대 배수를 정하는 것이 아니라, 어떤 해상도일 때의 크기를 흉내 낼 것인지를 선택하는 방식으로 지원한다.
파일:상세 내용 아이콘.svg   자세한 내용은 Retina 디스플레이 문서
를
의 번 문단을
의 부분을
참고하십시오.

3.3. 리눅스

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

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

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

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

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

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

X11만 지원하는 프로그램에 경우 Wayland에서는 XWayland를 통해 실행을 하게 되는데, X11와 Wayland의 렌더링 방식 차이로 인해 1.25(125%)같이 정수가 아닌 배율로 설정시 XWayland로 실행되는 프로그램이 흐리게 보이는 문제가 있다.

현재 KDE6에서 폰트가 깨지는 오류가 있다. QT 업데이트로 해결될 예정.

4. 웹 브라우저의 HiDPI 지원

웹 브라우저의 경우 운영 체제에서 스케일링 배율 정보만 받고 컨텐츠 스케일링은 독립적으로 한다.

다만 웹 또한 개발자가 이를 감안해서 디자인을 하여야 하는데 상기한 대로 디자인에 굴림, 돋움과 같은 글꼴을 사용하고 이런 글꼴이 문제가 되는 곳은 사실상 Windows밖에 없기 때문에 Windows가 HiDPI지원이 부족하다는 식으로 호도되기도 한다.

웹에서 보통 이런 점을 감안하는 경우, 버튼등을 만들 때 비트맵 이미지를 사용하지 않고 CSS나 SVG와 같이 벡터로 렌더링할 수 있는 이미지를 사용하거나 HTML의 <picture> 태그나 <img>의 srcset을 사용하여 여러 배율로 제작된 비트맵 이미지를 각각 지정하여 최적화된 컨텐츠만 표시하도록 되어 있으며, 한글 글꼴 또한 CSS의 <resolution>을 사용하여 저런 글꼴들을 우회하여야 한다. 그러나 많은 한국 웹 사이트들이 이런 UX적인 요소를 대체로 전혀 신경쓰지 않다 보니 한국어 Windows 사용자들에게서 Windows가 HiDPI가 안 좋다는 인식을 심어주는 악순환이 반복되고 있다.

[1] 동일 크기의 글자 하나를 표시할 때 픽셀을 16개만 사용할 걸, 64개를 사용하여 선명하게 표현하는 식. [2] 삼성전자 애니콜의 저가 기종(C230, 블랙/화이트 UI 시기에 나오는 S 계열, LG텔레콤용 저가형을 제외한 일부 W 계열)에 많이 탑재되어서 악명이 높았다. 2009년 슬림스타일 이후로는 더 이상 나오지 않는다. [3] 다만 일본은 한자를 자주 쓸 수밖에 없기 때문에 한국보다 더 고해상도였던 480×800(WVGA) 이상 피처폰이 유행했다. [4] 갤럭시 S(4.0"), 갤럭시 S II(4.3"), 베가 레이서(4.3") 등. [5] 바이오P 등 몇 차례의 시도가 있었지만 여러가지 요소가 겹치면서 실패하거나 전문가용 제품으로 극소수만 팔리던 실정이었다. [6] 이 때문에 Windows 3.x에서 돌아가던 프로그램을 Windows 95에서 돌리면 글자가 겹치거나 깨지는 일이 가끔 있었다. 이럴 때는 DPI 설정에서 72 PPI(125%)로 맞춰 주면 제대로 나왔다. 또한 DOS 시절 대부분의 프로그램이 72 PPI로 나왔는데 이 설정을 외부적으로 지금까지 유지하는 프로그램이 아래아 한글이다. 편집화면 배율이 기본 125%로 잡혀 있는 것이 그 흔적이다. 물론 100%로 되돌리면 다른 윈도우 프로그램과 같은 크기로 나온다. [7] 이는 4K UHD 모니터 두 개만 써도 9x의 최소화된 프로그램이 노출된다는 이야기다. 그러나 이는 예시일뿐, 실제로는 Windows 9x가 돌아가는 하드웨어는 HDMI나 DP가 없어 UHD 해상도를 출력할 수 없다. Windows 9x가 돌아가는 하드웨어의 그래픽 카드에 달린 디스플레이 출력 포트는 DVI와 D-Sub이며, DVI는 듀얼 링크로 출력해도 2560×1600이, D-Sub는 1920×1200이 최대 해상도이다. [8] 게다가, 이러한 리소스 공간은 일정한 크기로 고정되어 있는 구조이기 때문에 램을 추가 장착해도 해결되지 않는다. [9] 동일한 1920×1080 FHD 해상도여도, 크기 등 DPI를 파악하여 (노트북이라던지...) 상황에 따라 기본값 설정을 변경한다. [10] x2, x3, x4 등. [11] x1.5, x2.5, x3.5 등. [12] 2015년 7월에 정식 공개된 Visual Studio 2015도 HiDPI와 관련해서 문제가 발생하는 경우가 있다. WPF에 단순 버튼만 나열된 테스트 프로그램임에도 불구하고 제작한 프로그램이 UI 쪽에서 문제가 발생했다. [13] 창이 각기 다른 DPI를 가진 모니터로 이동되거나 설정에서 DPI를 변경하였을 때 프로그램에 WM_DPICHANGED이벤트가 전달된다. [14] CS6까지는 지원하지 않는다. Adobe Illustrator CC는 Per-monitor awareness가 지원되지만 컨텍스트 메뉴가 제대로 스케일링되지 않는다. Adobe Photoshop CC은 Per-monitor awareness가 지원되지만 스케일링 배율을 100%, 200% 두 가지만 지원했다가, CC 2018 버전에서 완전히 지원하게 되었다. [15] 참고로 Windows 문자표는 기본 프로그램임에도 HiDPI가 적용되지 않아서 UI가 잘려나온다. Windows 95부터 있었던 오래된 프로그램인 탓이 큰 듯하다. 작업 관리자를 열어서 프로세스 목록에서 '문자표'를 선택한 뒤 우클릭해서 최대화를 하면 옆으로 잘려나간 부분을 볼 수 있다. [스킨강제확대] 스킨을 강제로 확대하는 방식이기 때문에 완벽한 지원은 아니다. [스킨강제확대] [18] 시스템의 화면 배율 설정과 가상머신의 화면 배율 설정을 동기화해주는 기능이 내장되어 있다. [19] 초창기에 나온 Microsoft Store 앱의 경우 제대로 지원하지 않는 경우도 존재했지만, Windows 10의 출시 이후 해결되었다. [20] 2014 VP와 NEO는 메뉴가 굴림체로 되어 있기 때문에 HiDPI 환경에서 상당한 괴리감이 느껴진다. 2018에서 고딕 계열 글꼴로 변경되었다. [21] 100%, 125%, 150%, 200% 지원. [22] 내부 아이콘 및 일부 버튼들은 뭉개지거나 깨진다. 테마 내 이미지 해상도가 HiDPI를 지원할 만큼 충분히 높지 않아서 생기는 문제로, 개발자는 해결할 수 없는 부분이라고 답했다. [23] 200% 이상의 배율을 지원하지 못하는 반쪽짜리 지원이다. 예로서, 4K 노트북 등으로는 제대로 사용할 수 없다. [스킨강제확대] [25] '시스템'과 차이가 있을 수도 있고 없을 수도 있다. 효과가 있는 경우는 글꼴이 뚜렷해진다. 이게 기본값인 걸로는 대표적으로 '장치 관리자'가 있다. [26] 여기서 고급은 영어 원문으로 enhanced이다. "고급"은 오역이고 "향상된"이 의미상 맞겠지만 최근 MS의 번역 수준은.. [27] 대체로 GTK 본진인 GNOME과 Qt로 작성된 KDE가 HiDPI 지원이 잘 돼있는 편이다. [28] 오픈 소스 프로그램이 주류인 리눅스는 버그가 발생하면 제작자에게 수정을 요청하거나 본인이 뜯어고치면 되므로 버려진 프로그램이 아닌 이상 과도기적 프로그램들이 그리 많지 않다.

분류