Jump to content
과거의 기술자료(읽기 전용): https://tech.devgear.co.kr ×
과거의 기술자료(읽기 전용): https://tech.devgear.co.kr

이 사이트 검색

검색 태그: 'high dpi'.

  • 태그로 검색

    태그 사이를 쉼표(,)로 구분하세요.
  • 작성자로 검색

콘텐츠 유형


게시판

  • 엠바카데로 (Embarcadero) 개발도구: 델파이 (Delphi), C++빌더 (C++Builder), RAD 스튜디오 (RAD Studio)
    • [기술 Q&A 게시판] 델파이, C++빌더, RAD 스튜디오
    • [설치/등록 Q&A 게시판] 델파이, C++빌더, RAD 스튜디오
    • [기술 기고 게시판] 델파이, C++빌더, RAD 스튜디오
    • [포트폴리오 게시판] 내가 참여한 프로젝트/프로그램 소개
    • [구인 게시판] 개발자 채용/프로젝트 의뢰
  • 엠바카데로 (Embarcadero) DBMS: 인터베이스 (InterBase)
    • [기술 Q&A 게시판] 인터베이스
    • [설치/등록 Q&A 게시판] 인터베이스
    • [기술 기고 게시판] 인터베이스
  • 비주얼 스튜디오 (Visual Studio) 관련 도구
    • [기술 Q&A 게시판] 비주얼 어시스트
    • [설치/등록 Q&A 게시판] 비주얼 어시스트
    • [기술 기고 게시판] 비주얼 어시스트
  • 구록 (Gurock) 테스트도구: 테스트레일 (TestRail)
    • [기술 Q&A 게시판] 테스트레일
    • [설치/등록 Q&A 게시판] 테스트레일
    • [기술 기고 게시판] 테스트레일
  • 아이데라 (Idera) 데이터 도구: 아쿠아 데이터 스튜디오 (Aqua Data Studio), ER/Studio 등
    • ER스튜디오 (ER/Studio)
    • 아쿠아 데이터 스튜디오 (Aqua Data Studio)
  • API레이어 (Apilayer) 개발 도구: API레이어 (Apilayer)
    • [Q&A 게시판] API레이어 (Apilayer)
  • 엠바카데로 (Embarcadero) 라이선스 서버: ELC (Enterprise License Center)
    • [게시판] ELC (Enterprise License Center) 라이선스 서버
  • 이 사이트 이용 관련
    • [게시판] 이 사이트 관련 이용 팁과 Q&A

Categories

  • 이달의 기술자료: 엠바카데로
  • 비디오 세미나
    • UX Summit
    • DelphiCon
    • CodeRage
    • 데브기어 세미나
    • Skill Sprint
  • 기술백서(PDF)

Categories

  • 시작하기
  • 설치/등록/라이선스
  • 튜토리얼
  • 도서

Categories

  • RAD 스튜디오 역사관
  • 11 알렉산드리아
  • 10.4 시드니
  • 10.3 리오
  • 10.2 도쿄
  • 10.1 베를린
  • 10.0 시애틀
  • XE8~XE
  • 2010~6.0

...에서 결과 찾기

검색어 일치 조건


최초 작성일

  • Start

    End


최종 변경일

  • Start

    End


개수로 필터링...

가입

  • Start

    End


Group


자주 쓰는 도구

  1. 데이비드 밀링턴 (David Millington) 의 Windows 10 and Modern High DPI Display Support in Delphi and C++Builder 를 번역했습니다. (원문 작성 시기: 2019년 9월) 요즘 화면은 크기와 해상도가 몇년 전에 비해 크게 높아졌다. 지금 이 글을 작성하고 있는 맥북에는 1920x1080 24인치 외부 모니터가 연결되어 있고 이 맥북 프로의 화면은 2880x1800 15인치 레티나이다. 세로를 기준으로 비교하면, 외부 모니터 화면은 맥북의 레티나 화면에 비해 한줄에 들어있는 픽셀수는 3분의 2밖에 되지 않지만, 길이는 1.25배 더 크다. 따라서 인치당 픽셀의 수는 크게 차이난다. 외부 모니터는 인치당 90 픽셀이고, 맥푹 프로는 인치당 227픽셀이다. 거의 2.5배 정도(정확히는 2.44배) 차이가 난다. 이런 차이와 관련하여 High DPI라는 용어가 널리 사용된다. DPI는 'Dots per inch' 즉 '인치 당 점의 갯수'이다. 이 용어는 인쇄 분야에서 사용되던 점(Dot)과 모니터에서 사용되던 픽셀(Pixel)간에 다소 혼란스러운 바가 있긴하다. 고해상도 열풍은 애플이 주도했다. 2010년 아이폰4에서 처음으로 '레티나' 디스플레이를 적용하기 시작했고 이어서, 2012년에 맥북 프로 라인에 적용했다. 그러나 더 높은 해상도 즉 물리적으로 크기가 같은 영역에 더 많은 픽셀이 들어가는 화면으로 인해 문제가 생겼다. 특히 윈도우의 경우, 전통적으로 UI 레이아웃은 실제 물리적인 화면의 길이가 아니라 픽셀 단위로 계산한다. 툴바에 있는 아이콘은 항상 16 x 16 픽셀이 기본 크기이고, 버튼의 표준 크기는 너비가 75 픽셀이고 높이가 25 픽셀이었다 (델파이가 아닌 일부 다른 개발 도구로 만든 UI 애플리케이션에서는 24 픽셀). 하지만 화면 해상도가 높아짐에 따라, 픽셀 하나의 크기가 현격하게 작아지게 된다. 툴바의 아이콘이 지금 내 외장 모니터에서는 실제로 0.44cm인데, 내 맥북 프로에서는 0.17cm 이다. 이 문제를 해결하기 위해 윈도우 7에서 High DPI 지원을 시작했지만, 완전하고 견고하게 이 문제를 해소한 것은 윈도우 10 크리에이터 업데이트에서 도입된 'perMonitorV2' High DPI 지원이다. (버전2 라는 이름을 통해서 우리는 윈도우에서 High DPI를 지원하는 과정이 상당히 복잡하고, 선택지가 많고, 이슈 해소를 위해 반복을 통해 발전함을 알 수 있다.) 윈도우 10에서 perMonitorV2 고해상도를 지원하는 애플리케이션은 각 화면이 표현되는 화면의 해상도에 따라 동적으로 창의 크기를 맞출 수 있다. 즉 내 외장 모니터에 있던 앱을 드래그하여 맥북의 모니터로 옮기면 (비 클라이언트 영역, 테마 렌더링 등등을 포함하여) 창의 배율이 모니터에 맞게 조정어서 물리적인 크기를 잘 유지한다. 앱의 여러 창들이 각각 다른 모니터에서 표현될 때도 마찬가지이다. 2018년 11월부터 델파이와 C++빌더는 10.3 버전을 통해에서 (윈도우 UI 프레임워크인) VCL에 High DPI 지원을 시작했다. 그 이후로도 지속적인업데이트들을 통해 실제로 많은 개발자들이 VCL 고해상도 지원 기능을 잘 활용하고 만족하고 있다. VCL 스타일 (테마)과 IDE 자체에 대한 High DPI 지원 계획도 로드맵에 있다. (2019년 9월) 현재는 VCL에서만 High DPI를 지원하고 있다. 이미지 VCL의 High DPI 지원은 자동 방식이다. Project > Options > Manifest page 에서 ‘DPI Awareness’ 옵션을 지정하기만 하면 모든 UI 컨트롤의 크기와 위치가 알맞게 반영된다. 컨트롤이 화면에 표현되는 방식은 (선이나 테두리 등) 모양을 직접 그리기 또는 윈도우 테마 (윈도우 10에서는 High DPI도 지원)를 통해서 그리기 중 하나이기 때문에 앱과 해당 컨트롤들은 정확히 동일하게 표현된다. 단지 선명도가 모니터에 따라 살짝 차이가 날 뿐이다. 단 한 가지 예외가 있는데... 바로 이미지이다. 대표적으로 툴 바의 아이콘을 들 수 있다. 윈도우는 이미지를 이미지 리스트에 저장하는데, 이미지 리스트는 크기가 하나인 이미지들이 모여있는 곳이다. 이제 문제가 무엇인지 눈치챘을 수도 있겠지만, High DPI 화면에서 툴바 버튼 컨트롤은 기본 픽셀 크기의 2.5 배까지 커지지만, 이미지 리스트에 있는 버튼의 이미지는 알맞게 대응할 수 없으므로 16x16 이미지가 40x40으로 늘어가기 때문에 뿌옇게 표현된다. 16x16 픽셀 아이콘 동일한 16x16 아이콘이 2.5 배(40x40)로 늘어나서 표현된 모습 대부분의 High DPI 애플리케이션들이 이렇게 표시한다. 선명하게 40x40으로 표현된 모습 델파이와 C++빌더가 사용하는 방식 델파이와 C++빌더 기술이 놀라운 기술이 여기에 들어 있다. High DPI VCL 지원을 RAD스튜디오 10.3에 담아 출시할 때, 엠바카데로는 윈도우 자체의 High DPI perMonitorv2만 지원한 것이 아니라 더 나아가 이미지 확대/축소 문제를 해소했다. 이 문제는 윈도우 이미지 리스트와 관련되어 있으며 윈도우 스스로 아직까지 해결하지 못한 문제이다. 우리는 가상의 이미지 리스트를 도입하여 High DPI를 담고, 어떤 DPI 또는 화면 배율에도 선명한 이미지를 표현하도록 했다. 가상 이미지 리스트는 (HIMAGELIST 핸들이 있는) 윈도우 이미지 리스트 등 기존의 TImageList와의 하위 호환성을 완벽하게 지키면서도 확대/축소를 반영한다. 우리 개발 도구의 가치를 알 수 있는 좋은 사례이다. 우리 프레임워크를 사용하지 않고 이렇게 구현하려면 개발자가 엄청난 수작업을 해야할 것이다. VCL의 High DPI 이미지 리스트 컴포넌트에 대한 자세한 내용을 확인해보자.
  2. Anbarasan의 Quickly Migrate and Modernize Your Delphi/C++ Apps Using FastReport With Windows High DPI Setup 을 번역했습니다. (원문 작성 시기: 2020년 11월) 디스플레이 패널의 물리적 공간 당 픽셀 수는 점점 더 많아지고 있어서 DPI (인치 당 도트수)가 높은 모니터가 많아졌다. 예전에는 디스플레이 대부분이 96 DPI 즉, 1 인치 당 96 픽셀이 들어있었지만, 2017년에는 거의 300 DPI가 넘는 것들도 생겨났다. 이제 시중에는 SD, Full HD, 4K 울트라 HD, 8K 울트라 HD 등 다양한 모니터가있다. 우리가 사용하는 노트북이나 화면이 작은 데스크탑에서 화면 배율 팩터/DPI를 변경할 수 없으면 사용하기가 매우 어렵다. 더 나아가 Full HD, 4K 울트라 HD, 8K 울트라 HD 모니터에서는 훨씬 더 복잡하다. 우리의 애플리케이션들은 이 모든 것을 다룰 수 있어야 한다. 어떤 사용자가 어떤 사양의 모니터를 사용할 지 모르기 때문이다. 화면 배율 팩터/DPI가 변경되는 일반적인 상황 몇 가지를 살펴보자: 모니터 여러 대를 사용하는데, 각 모니터의 화면 배율이 서로 다르고, 애플리케이션이 한 모니터에서 다른 모니터로 옮겨지는 경우 (예. 모니터 1은 4K이고 모니터 2는 1080p 화면) DPI가 낮은 외부 모니터를 DPI가 높은 노트북에 연결 또는 연결 해제하는 경우 (또는 그 반대의 경우) DPI가 높은 노트북/태블릿에서 원격 데스트탑을 통해 DPI가 낮은 장비를 연결하는 경우 (또는 그 반대의 경우) 애플리케이션이 작동하고 있는 중에 윈도우의 화면 배율 팩터 설정을 변경하는 경우 데스크탑 애플리케이션은 자신이 DPI Scaling을 지원하는 지를 윈도우에게 알려야 한다. 이 정보가 전달되지 않으면 윈도우 시스템은 일단 해당 데스크탑 애플리케이션은 DPI를 인식하지 않는다고 간주하고, 화면에 맞게 비트맵을 확대/축소 한다. 애플리케이션은 자신의 DPI 인식 모드를 Unaware, System, Per-Monitor, Per-MonitorV2 중에서 하나로 설정함으로써 윈도우가 해당 애플리케이션을 화면에 표현할 때 DPI 확장을 어떻게 처리할 지 명확하게 알려주게 된다. 일반 애플리케이션을 Per-MonitorV2 인식으로 업데이트할 때에는, UI 레이아웃을 제어하는 코드 역시 업데이트 되도록 해야 한다. 이 처리는 애플리케이션이 초기화되는 시점 뿐만 아니라 DPI 변경 (Win32의 경우 WM-DPICHANGED 윈도우 메시지) 알림을 받을 때마다 반영되어야 한다. 델파이 애플리케이션을 High DPI로 마이그레이션 할 때 꼭 알아두어야 하는 점들은 무엇일까? DPI Awareness 모드를 설정한다: Project > Options > Application > Manifest-DPI Awareness 에서 Per-MonitorV2를 선택한다. Screen.PixelsPerInch 에 주 모니터의 DPI를 사용한다. TImagesList 대신 TVirtualImageList를 사용한다. 모든 사용자 정의 그리기 작업에서 절대 위치를 확인한다. Control.CurrentPPI를 사용하여 각 컨트롤들이 표현되는 현재 PPI값을 받아낸다. 대화상자 혼합 모드 (SetThreadDPIAwarenesscontext) 폼의 OnBeforMonitorDPIChanged / OnAfterMonitorDPIChanged 이벤트를 사용한다. 주의: 플랫폼과 애플리케이션을 개발한 델파이 버전 호환성을 확인해야 한다. 델파이와 패스트리포트(FastReport)의 High DPI 컨트롤들: TControl: ScaleforPPI, ChangeScale, ScaleControlsForPPI와 같은 프로시저들은 High DPI 변경을 도와준다. TFrxBAseForm: UpdateResources, UpdateFormPPI, ProcessPreferences와 같은 프로시저와 WM_DPICHANGED 윈도우 메세지는 패스트리포트 폼의 DPI 변경을 도와준다. TFrxDPIAwareCustom: DoPPIChanged, GetScale과 같은 프로시저와 WM_DPICHANGED_AFTERPARENT 윈도우 메세지는 패스트리포트의 사용자 지정 컨트롤 DPI 변경을 도와준다. Fast Migration to Windows 10 High DPI 비디오에서 데모를 확인해보자!
  3. 마르코 칸투 (Marco Cantu)의 VCL Support for Per Monitor v2 and GetSystemMetrics Coming in 10.3 를 번역했습니다. (원문 작성 시기: 2018년 11월) RAD 스튜디오 10.3 버전부터, 마이크로소프트 윈도우 10에서 최근에 추가된 Per Monitor v2 (모니터 개별 V2) 모드 지원이 반영되었다. (VCL 애플리케이션도 일종의 윈도우 애플리케이션인데) 해상도가 다른 모니터 여러개를 윈도우 지원하기는 상당히 복잡하다. 지금까지는 GetSystemMetrics 와 같은 윈도우 API를 통해서 플랫폼 요소의 크기를 요청하면 주 모니터의 정보만 받을 수 있었다는 점 등 여러가지 이슈로 인해서 꽤 어려웠다. 예를 들어, 애플리케이션 안에 있는 스크롤 바의 크기를 해상도가 다른 보조 모니터에서 문제없이 표현하는 것 조차 쉽지 않았다. 마이크로소프트 윈도우 10 업데이트에서 새 API가 도입됨에 따라 이 작업은 이제 간편해졌다. 일명 윈도우 10 크리에이터 업데이트 (빌드 1703)부터 GetSystemMetricsForDPI가 새로 추가되었기 때문이다. 이 새 윈도우 API를 보다 폭넓게 활용할 수 있도록 우리는 VCL 라이브러리에 반영하기로 했는데 이 새 API를 호출하기만 해서는 쓸만하지 않았다. 그 이유는 윈도우 7 등 해당 윈도우 10 업데이트 이전의 버전과 호환성이 깨지기 때문이었다. 따라서 이 문제를 해결하기 위해 우리는 부가적인 작업을 해야만 했다. 첫째, 우리는 VCL.Classes 유닛에 GetSystemMetricsForWindow라는 새 전역 함수를 하나 추가했다. 이 함수는 해당 윈도우 API를 랩핑하고 있는데, 만약 윈도우가 최근 버전이라서 GetSystemMetricsForDPI를 사용 할 수 있으면 이것을 사용하고, 그렇지 않으면 윈도우의 전통적인 GetSystemMetrics를 사용한다. 이 함수에는 파라미터가 하나 추가되었는데 여기에는 해당 윈도우 API에 전달할 관심있는 창을 가리키는 (그리고 그 창이 표현되고 있는 모니터들에 대한 정보를 간접적으로 전달할 수 있는) 윈도우 핸들이 들어간다. 둘째, 기존의 VCL 코드 (VCL 라이브러리 내부에 구현된 코드, 델파이 사용자가 만든 커스텀 컴포넌트와 애플리케이션의 코드 )를 업데이트 하는 작업이 간편하도록, 우리는 TControl에 GetSystemMetrics라는 메소드를 새로 추가했다. 이 메소드는 GetSystemMetrics 윈도우 API 와 이름이 같고 파라미터 호환성도 지켜진다. 따라서 기존에 컴포넌트에서 사용된 해당 API 호출이 새 메소드로 재전달 될 수 있다. 즉, 컨트롤을 담고 있는 부모 창의 핸들을 파라미터에 담아서 GetSystemMetricsForWindow를 호출하게 된다. 이 방식 덕분에, 이와 관련된 코드 대부분은 전혀 수고하지 않아도 자동으로 “전환”된다. 마지막으로, 우리는 TControl에 새 읽기 전용 속성인 CurrentPPI를 추가했다. 이 속성은 해당 콘트롤이 표현되고 있는 모니터의 DPI를 반환한다. 예제로, 버튼의 OnClick 이벤트에 아래의 코드가 있는 간단한 VCL 애플리케이션을 하나 만들었다. procedure TfrmSystemMetrics.btnRefresh (Sender: Object); begin Lable2.Caption := ‘Current: ‘+ GetSystemMetrics (SM_CXVSCROLL).ToString; end; 위 코드는 델파이 초기 버전부터 해당 윈도우 API 함수를 불렀다. 이제는 이 GetSystemMetrics 호출이 해당 폼의 핸들을 전달할 수도록 보강되었다. 따라서 새 윈도우 API 함수를 호출하고, 해당 모니터 별로 고유한 결과를 받을 수 있다. 이 샘플 애플리케이션에서는 폼의 OnCreate 이벤트에서도 같을 호출을 하는데 그 결과 폼이 생성될 시점에 사용된 고해상도 주 모니터의 값 (34 픽셀)이 찍힌다. 그리고 나서 이 폼을 해상도가 더 낮은 (스크롤 바가 17 픽셀을 차지하는) 보조 모니터로 옮긴 후에 버튼을 클릭하면, 같은 호출이지만 결과가 다르다 (아래 결과 화면을 보자). 그림. 동일한 GetSystemMetrics를 호출하지만, 결과는 34와 17로 모니터의 DPI에 따라 다르다. 지금까지 설명한 핵심 구현과 별개로, 윈도우의 이러한 새 모델을 수용하기 위해, 우리는 VCL과 VCL 스타일을 상당히 업데이트했다. 그리고 마이크로소프트에서 새로 지원하는 DPI 모델을 수용할 수 있도록 컴포넌트 제작자들 역시 우리와 같은 작업을 진행 하기를 권한다. 우리는 대부분의 경우 코드를 그대로 두면 되었다. 하지만, 일부 메트릭스는 모니터 독립적이어서 변함없이 주 모니터에만 의존한다. 그런 경우에는 개발자가 Windows 유닛을 이용하여 해당 호출을 수정하는 방식 즉 Windows.GetSystemMetrics (SM_xxx)를 사용하여 해당 윈도우 API를 호출하도록 강제해야 한다. 만약 데이터 모듈이나 전역함수 등 TControl을 상속하지 않은 곳에서 이런 호출을 하고 있다면 코드 구조를 다시 고려해볼 필요가 있다. 끝으로, 델파이 애플리케이션의 경우 IDE에 프로젝트 옵션이 추가되었으므로, 매니페스트(manifest)에서 이 기능을 활성화할 수 있다. 그리고 이 Per Monitor v2 옵션은 새 VCL 프로젝트에서는 기본으로 지정된다. 마지막으로 알아두어야 할 한가지 제약 사항이 있다. Per Monitor V2 (와 윈도우의 기타 수많은 High DPI 지원)은 MDI 자식 창 모델을 전혀 지원하지 않는다. 마이크로소프트는 이미 MDI와 관련된 버그 리포트에 대해 전혀 대응하지 않고 있다. 따라서 MDI가 아닌 다른 다중-창 모델 (다중 유동형 창, 도킹 판넬, 탭으로 구성된 창, 등등)으로 전환할 것을 추천한다.
  4. 짐 맥키트(Jim McKeeth)가 작성한 High-DPI on Windows 10을 번역했습니다. 모니터와 관련하여 우리는 종종 해상도(예: 1920x1080)와 대각선 길이(예: 27" 또는 68.58cm)를 이야기한다. 이 정보와 피타고라스 정리를 활용하면, DPI를 파악할 수 있다. 아래의 DPI와 PPI에 대한 설명을 참고). 해상도를 높이지 않는다면, 화면이 커질수록 DPI는 낮아진다. DPI = (sqrt (sqr (폭) + sqr (높이)) / 대각선 처음에 윈도우는 모든 모니터의 DPI를 96로 간주했었다 (실제로는 72 PPI를 사용한다). 윈도우 XP에서는 GDI+가 추가되어서 해상도에 의지하지 않고도 텍스트를 확대/축소할 수 있게 되었다. 윈도우 비스타(Vista)에서는 High DPI 디스플레이 지원이 추가됨에 따라 더 많은 픽셀을 사용할 수 있게 되어서 텍스트는 더 선명하게 이미지는 더 자세하게 표현할 수 있어 졌다. 하지만, 앱이 High DPI를 지원한다고 알려주지 않는 경우에 윈도우는 앱을 여전히 96DPI로 취급했다. 윈도우 7에서는 모니터의 실제 픽셀 밀도을 파악하여 값을 얻을 수 있게 되었다. 윈도우 10에서는 모니터 별로 독립적으로 DPI에 맞게 확대/축소할 수 있게 되었다. (96 DPI 이상인) High DPI 모니터를 사용하는 경우, 윈도우에서 화면 배율을 지정하면, 확대된 화면에서 내용이 너무 작고 읽기 힘들어 지는 것이 아니라, 더 선명한 폰트와 더 자세한 이미지를 볼 수 있다. 그림. 윈도우 10 화면 설정에서 화면 배율 지정 윈도우 10의 이 변화가 개발자에게 의미하는 바는, 10.3 리오부터 윈도우 VCL로 High DPI 애플리케이션 개발할 수 있게 되었다는 점이다. High DPI 이미지 리스트 지원 Per Moniter V2 지원 새로운 스타일들 윈도우 API들 업데이트 마르코 칸투는 Per Monitor v2 지원에 대한 글을 통해서 개발자가 윈도우 10의 새 기능을 활용하여 모니터 별로 해당 DPI를 파악할 수 있는 앱을 개발할 수 있게 되었다는 점을 설명했다. 이 DPI Awareness 옵션은 Project > Optios > Application > Manifest에 있다. 새 VCL 프로젝트를 만들면 디펄트 설정인 Per Monitor v2가 반영된다. 기존의 프로젝트에서 High DPI를 지원하려면 이 옵션을 직접 Per Monitor v2로 바꾸면 된다. 그림. RAD 스튜디오 프로젝트 옵션 설정에서 DPI Awareness 지정 VCL프로젝트에서 Per Monitor v2 옵션을 지정하여 빌드한 VCL 앱은 자동으로 화면에 맞추어 크기를 변경한다. 하지만, 관련하여 VCL.Classes 유닛에 GetSystemMetricForWindow 함수가 새로 추가되었다. 이 함수는 윈도우의 새 API인 GetSystemMetricsForDPI를 활용한다 (참고로, 이 새 윈도우 API는 안에서 이전의 GetSystemMetrics를 활용한다). GetSystemMetricForWindow 함수를 이용하면 개발자는 앱이 표현되고 있는 현재의 모니터에서 파악된 내용을 기반으로, 앱의 각 창 별로 해당 매트릭, 해상도, DPI를 얻을 수 있다. TControl (과 그 하위 컨트롤)에는 GetSystemMetrics 메소드가 제공된다. 이 메소드를 호출하면 업데이트된 정보가 자동으로 제공되므로 기존 코드를 쉽게 마이그레이션 할 수 있다. TControl에는 이 메소드 이외에도 CurrentPPI 속성이 있다. 그림. TControl (과 그 하위 컨트롤)은 화면의 DPI에 맞추어 이미지를 선명하게 표현할 수 있다. 새 VCL High DPI 이미지 리스트는 마술같은 멋진 컴포넌트로써 TImageCollection과 TVirtualImageList로 구성된다. 이 컴포넌트 세트 사용에 대한 내용은 데이비드 밀링턴의 글에 잘 설명되어 있다. 이 컴포넌트 세트 덕분에 High DPI 화면에서 고해상도 그래픽를 자동으로 활용하는 앱을 정말 쉽게 만들 수 있다. 새 이미지 리스트는 윈도우의 기본 이미지 리스트 이상을 담고 있어서 여러분의 VCL 앱이 멋지게 표현될 수 있도록 한다. 그림. TImageCollection에는 이미지 별로 다양한 해상도의 이미지를 추가/편집/삭제할 수 있다 이 기능들을 (겟잇에서 제공하는) 10.3 리오에서 추가된 새 VCL 스타일과 함께 사용하자. 개발자는 VCL 앱이 윈도우 10에서 작동될 때 어떤 모니터에서도 멋진 모습이 되로록 하는데 필요한 모든 것을 다 가졌다. 10.3 리오에서는 이것 이외에도 많은 새 기능과 업데이트가 있다. DPI와 PPI에 대한 설명 DPI는 이미지를 구성하는 각 점들의 밀도를 측정한 것이다. 이 점들은 화면이나 지면에 표현될 때 사용되는 점이다. 하지만, 지금은 모니터 화면에서 이미지를 표현하는 개별 요소인 픽셀을 중심으로 이야기 해보자. 인치 당 점의 갯수인 DPI는 화면 상에서는 1인치 당 점인 픽셀의 갯수이다 (1인치가 2.54cm이므로 254DPI는 100DPCM이고, 100DPI는 39.37DPCM이지만, 지금은 DPI만 사용하기로 하자). 종이에 찍히는 잉크 점 하나와 화면에 펴현되는 픽셀 하나 사이에는 기술적인 차이점이 있다. 따라서 모니터에서는 Pixels Per Inch (PPI)가 정확한 용어이지만 DPI와 PPI가 같은 의미로 사용되는 경우가 흔하다. 대부분의 모니터에는 서브 픽셀(sub-pixel)이 있다. 서브 픽셀은 (빨강, 녹색, 청색와 아마 하얀색인) 각 개별 색상 요소이며, 모여서 하나의 색상 픽셀을 형성한다. 화면의 각 개별 색상 요소인 서브 픽셀의 밀도가 달라지게 되면, 화면의 색상 표현 역시 크게 달라진다.
  5. 데이비드 밀링턴 (David Millington)이 작성한 New in RAD Studio 10.3: High DPI Image List for Windows를 번역했습니다. RAD 스튜디오 10.3에서는 High DPI 지원에도 많이 신경을 썼다. 마르코 칸투가 쓴 VCL에서 Per Monitor v2 지원에서 언급되었듯이, 10.3부터는 VCL 애플리케이션이 화면 배율에 알맞게 축소/확대 되며, High DPI 화면 또는 확장된 화면에서 잘 표현된다. 이때 중요한 점은 툴바, 메뉴, 버튼 등 글리프(Glyph)를 사용하는 모든 곳에서 해당 그래픽 자원을 얼마나 잘 High DPI에 맞추어 확대/축소하는가이다. 툴바에서 16×16 픽셀인 아이콘을 사용한다면, 이 애플리케이션이 200% 확대된 곳에서 작동할 때에는 32×32 픽셀로 선명하게 표현되기를 원한다. 비록 High DPI API가 윈도우에 추가되긴 했지만, 윈도우 자체의 이미지 리스트에는 확대/축소 기능이 없다. TImageList는 이것을 감싸고 있으므로 마찬가지 제약이 있다. 따라서 화면의 DPI에 맞게 배율이 변하는 폼 안에서, 툴바 등 TImageList를 통해 사용되는 이미지들이 배율에 맞춰 선명하게 표현되게 하려면, 복잡한 추가 코드를 작성하지 않고는 어렵다. 그리고 VCL 콘트롤 대부분은 실제로 네이티브 윈도우 콘트롤이므로 윈도우의 네이티브 이미지 리스트와 HIMAGELIST 그리기 핸들에 밀접하게 묶여있다. 10.3에서 델파이와 C++빌더에는 완전히 새로운 이미지 리스트 콘트롤이 추가되었다. 자동으로 High DPI에 맞게 확대/축소되기 때문에 모니터나 배율에 상관없이 언제나 선명한 고해상도 이미지가 표현된다. 그리고 기존의 VCL 콘트롤 또는 윈도우 이미지 리스트와 완전히 호환되며, WinAPI를 호출할 때 사용할 수 있도록 HIMAGELIST 윈도우 핸들도 제공된다. 마법같지 않은가? 계속 읽어보자! TImageCollection 과 TVirtualImageList 새 이미지 리스트는 예전과 달리 두개로 나누어 구성된다. 이미지 컬렉션(단지 고해상도 이미지를 모아두는 역할)과 가상 이미지 리스트(이미지 컬렉션에 연결되어 상황에 따라 특정 크기의 이미지를 꺼내어 표현하는 역할)이다. 이미지 컬렉션 (TImageCollection) TImageCollection은 단순명확하다. 어디에 두어도 된다. 폼이든 데이터 모듈이든 TImageCollection을 놓아두고 그 안에 이미지를 추가하면 된다. TImageCollection에는 같은 이미지를 해상도 별로 여려개 넣을 수 있다. 예를 들어, 하나의 이미지를 16×16, 32×32, 128×128 픽셀로 각각 파일을 올리면, 실제로는 크기가 다른 이미지이지만 논리적으로 하나의 이미지로 취급된다. 그림. TImageCollection에는 이미지 별로 다양한 해상도의 이미지를 추가/편집/삭제할 수 있다. 논리적인 이미지 별로 서로 다른 해상도 파일을 올릴 때 수작업으로 할 수도 있지만, 이 파일들을 모아둔 폴더에서 한번에 올려도 TImageCollection이 알아서 유사한 이름 별로 묶고 크기를 파악한다. 파일명을 가지고 이렇게 구분하도록 하려면 Size Separator (구분자)를 지정한다. 예를 들어, ‘foo-16.png’, ‘foo-32.png’, ‘bar-16.png’ 파일을 올리면, 논리적 이미지는 foo와 bar 두개가 생기고 foo는 16×16과 32×32 버전을 가진다. 여기에 사용되는 파일명 내의 구분자는 이미 시중의 아이콘 라이브러리에서 널리 사용되고 있는 것들이므로 아이콘을 사서 바로 임포트할 수도 있다. TImageCollection은 PNG 이미지와 32bpp 비트맵 (알파 채널을 가지는 BMP 파일)을 지원한다. 32bpp가 아닌 비트맵은 구.TImageList에서와 마찬가지로 전통적인 컬러키 비트맵으로 취급한다. TImageCollection 안에서는 이미지에 이름을 주거나 카테고리를 지정할 수 있어서 관리하기가 좋다. 그 결과 알파을 인식할 수 있고, 다중 해상도 이미지를 담을 수 있는 컬렉션이 생긴다. 가상 이미지 리스트 (TVirtualImageList) TVirtualImageList 컴포넌트는 화면의 DPI/배율에 따라 알맞는 이미지를 표현한다. TVirtualImageList는 TImageCollection에 연결하여 사용한다. TVirtualImageList에는 이미지를 추가하거나 목록을 편집할 수 있는데, 연결된 컬렉션에 있는 이미지를 가져와서 지정한다. 또한 AutoFill 속성을 사용하면 연결된 컬렉션에 있는 모든 이미지를 자동으로 채울 수도 있다. 또한 기타 유용한 설정이 있다. 예를 들어, 비활성화 이미지 표시를 구.TImageList 보다 잘 할 수 있다 (회색 처리 그리고/또는 반투명 처리 등). TVirtualImageList는 화면 크기에 맞는 이미지가 사용된다는 점이 핵심이다. 이미지 리스트에 높이와 너비를 지정한다는 점은 구.TImageList와 마찬가지이지만, 그 의미는 다르다. 구.TImageList에서 높이와 너비가 각각 16으로 지정되면 표현되는 화면과 상관없이 무조건 16x16으로 표현 되었지만, TVirtualImageList에서 높이와 너비가 각각 16으로 지정하면 배율이 100%일 때 16x16으로 표현하라는 의미이므로, 화면 배율 변하면, 크기도 변한다. High DPI 창별 배율 (High DPI scales per-window)이란 서로 다른 폼에 서로 다른 배율이 적용될 수 도 있다는 의미이다. 이때 (DPI 변화에 맞추어 이미지 리스트가 확대/축소 해야하는 경우) 그 배율은 폼에 적용된 배율을 기준으로 한다. 따라서 TVirtualImageList는 폼에서만 사용할 수 있다 (TImageCollection과 달리 데이터 모듈에서는 사용할 수 없다. 데이터 모듈은 비시각적 콘트롤이므로 배율과 관련이 없기 때문이다). TVirtualImageList는 폼에 적용된 현재 배율을 파악하고, 이미지컬렉션에 있는 이미지 중 그 배율에 맞는 이미지를 가져와서 표현한다. TVirtualImageList에 지정하는 높이와 너비가 배율 100%를 기준으로 하기 때문에 이것이 가능하다. 만약 TVirtualImageList가 들어있는 폼에 적용되는 배율이 200%라면, 높이와 너비가 모두 16으로 지정된 TVirtualImageList는 실제로 32×32 아이콘을 그린다. 16의 200%가 32이기 때문이다. TVirtualImageList는 고해상도 이미지를 그린다. 크기에 딱맞는 이미지가 있으면 그것이 사용된다. 만약 딱맞는 것이 없으면 해상도가 더 높은 이미지를 가져와서 수준높은 확대/축소 알고리즘을 거쳐서 표현한다. 이런 이미지 처리 결과 캐시되기 때문에 이미지 별도 단 한번만 수행된다. TVirtualImageList는 TCustomImageList를 상속받았으며 HIMAGELIST 핸들이 있다. 따라서 WinAPI 메소드를 호출할 수 있다. 새 이미지 리스트로 컨버전하기 TImageCollection에는 구.TImageList에 들어 있는 이미지를 가져올 수 있는 도구가 제공된다. TImageCollection에서 오른쪽 클릭을 하여 구.TImageList 여러개에서 이미지들을 한꺼번에 임포트할 수 있다. 도움말 Docwiki에는 TImageCollection과 TVirtualImageList에 대한 자세한 도움말(영문 보기, 한글 자동 번역 보기)이 있다. 아키텍처와 컴포넌트에 대해 이 글에서 소개한 내용보다 자세히 설명되어 있고, 새 High DPI 이미지 리스트로 마이그레이션하는 방법과 베스트 프렉티스가 있다. 최종 결과 이미지 리스트 데모 화면의 스크린 샷이다. 100% 배율 화면: 800% 배율 화면: 이미지가 더 선명하고 깨끗하다. 새 High DPI 이미지 리스트 (TImageCollection 과 TVirtualImageList)는 DPI를 인식하여 배율에 맞는 고품질 이미지를 자동으로 반영한다. 기존의 TImageLists와 완전히 호환되고 예전 방식의 비트맵과 이미지 리스트를 임포팅할 수 있다. VCL 전체를 아우르는 PerMonitor V2의 High DPI 지원과 함께 사용하면 RAD 스튜디오 10.3 부터는 배율을 인식하는 시각적으로 훌륭한 고품질 앱을 만들 수 있다.
  6. IAN BARKER가 2019년 9월 19일에 포스팅한 High-re DPI and Per Monitor v2 with Delphi and RAD Studio 를 한글로 요약 정리한 글입니다. (원문에는 해당 옵션 설정 화면 이미지 등 보다 자세한 내용이 있습니다) 목차 배경 및 트렌드 마이크로소프트의 대응 델파이에 “Per monitor v2” 가 반영되기 전 버전의 이슈 10.3 리오에서 “Per monitor v2” 반영 보너스: 델파이의 프로젝트 옵션의 Manifest와 관련된 알아둘 만한 옵션들 배경 및 트렌드 컴퓨터에 해상도가 다른 각 모니터를 연결하여 동시에 사용하는 경우가 흔해졌다. 노트북 뿐만 아니라 테블릿에도 외부 모니터를 연결하여 다중 모니터를 사용한다. 마이크로소프트의 대응 “Per monitor v2” 기술을 윈도우 10에서 도입했다. 기능: 사용자가 각 모니터 별로 DPI 확대/축소를 지정할 수 있다. 활용 사례: 노트북에 HighDPI 모니터를 연결하여 사용하는 사용자가 노트북 화면에는 일반 해상도를, 큰 외부 모니터에는 더 높은 해상도를 지정할 수 있다. 이것은 각 픽셀의 폭과 높이 뿐만 아니라 PPI (Pixels Per Inch) 즉 실제 픽셀 밀도와 관련이 있다 델파이에 “Per monitor v2” 가 반영되기 전 버전의 이슈 델파이 10.3 이전 버전에서 만든 앱을 드래그하여 다른 모니터로 옮기면 픽셀 밀도의 변화를 알 수 있다. 화면이 선명하지 않거나, 확대/축소가 이상하게 되거나, 심지어 텍스트가 잘못된 곳에 표시되기도 한다. 그 이유는 96 DPI에서 작동하는 화면에 앱의 좌표가 맞춰져있었는데, 다른 모니터 (120 DPI 등)에서 표현되기 때문이다. 10.3 리오에서 “Per monitor v2” 반영 프로젝트 별로 매니페스드(Manifest)에 반영함으로써, 델파이로 만든 앱이 Per Monitor v2를 다룰 수 있음을 윈도우에게 알려줄 수 있다. 델파이 10.3 리오에서는 메인 메뉴 > project > options 을 선택하여 프로젝트 옵션 설정 화면을 연다. Application | Manifest 를 선택하고, DPI Awareness 에서 Per Monitor v2 를 선택한다. (기본 설정이 Per Monitor v2 이지만 한번 더 확인하는 것이 좋다) 위와 같이, 매니페스트 설정 이외에도, 10.3 리오에서는 화면의 DPI가 변경되면 앱에서 감지할 수 있도록 OnAfterMonitorDpiChanged 라는 새 이벤트가 추가되었다. 보너스: 델파이의 프로젝트 옵션의 Manifest와 관련된 알아둘 만한 옵션들 “Enable Runtime Themes“ 체크 박스 위치: Project > Options 를 열고, Application > Manifest를 선택하면 보이는 화면(11.0 버전에서는, DPI Awareness 옵션 위)에 있다. 설명: 테마를 반영하려면 체크되어 있어야 한다 (체크 즉 활성화된 상태가 기본 설정이다). 이 옵션의 역할은 델파이 7 당시의 TXPManifest 컴포넌트가 했던 역할과 실제로 비슷하다. 즉, 애플리케이션의 매니페스트에 추가 정보를 넣어서 네이티브 콘트롤을 렌더링할 때 특별한 방식으로 수행될 수 있도록 한다. 체크해 둘 것을 권장한다. 스크린 샷 등 보다 자세한 설명 보기 Execution level 선택 박스 위치: DPI Awareness 옵션 아래에 있다. 기능: 앱을 실행하는 윈도우 권한 수준을 조절한다. 선택 옵션은, “as invoker” “as invoker”는 기본 설정이며, 대체로 "as invoker"를 선택하면 무난하다. 해당 앱을 구동한 쉘(Shell) 또는 앱의 권한을 상속한다. 예를 들어, 앱을 실행한 Shell의 권한이 매우 제한적이면, 앱의 권한도 매우 제한적이다. 반대로, 관리자(Administrator) 권한으로 프로세스를 시작했다면, 앱의 권한도 관리자 권한이 적용된다. Highest available*: 가장 높은 권한 Require Administrator*: 관리자 권한 * 일반 사용자가 이 옵션으로 설정된 앱을 실행하려면, 관리자 로그인 비밀번호를 넣어야 실행할 수 있다.
  7. << DelphiCon 2020 목록으로 이동 DelphiCon 의 2020 시리즈 중, Leveraging High DPI in VCL Applications - Ray Konopka 의 한글 요약본입니다. 발표자 (Ray Konopka)는 CodeSite, Konopka Signature VCL로 유명한 Raize Software의 창업자이며, 월트 디즈니 어트렉션 테크놀러지의 수석 소프트웨어 엔지니어로서, 디즈니리조트, 디즈니랜드 등의 소프트웨어도 개발합니다. 도서 “델파이 컴포넌트 개발하기(Developing Custom Delphi Component)” 저자이기도 합니다. 델파이는 델파이로 만듭니다. 델파이는 11.0 버전에서 IDE 자체에 HighDPI를 적용하였습니다. 그 결과, 델파이 사용자들이 더 쾌적하게 개발할 수 있게 되었습니다. (모니터가 4K 이상이라면 더욱 효과가 큽니다) 여러분의 앱에서도 델파이 11.0과 같이 서로 다른 다중 모니터 특히 최근에 부쩍 많아진 High DPI 모니터 지원할 수 있습니다. 그 방법을 이 세션에서 설명합니다. 원본 비디오(YouTube) 보기 (54 min)를 권장합니다. 발표 자료도 참고하세요. 목차 High DPI 관련 핵심 개념 이제는 개발자가 '단 하나의 DPI' 를 기준으로 잡지 못할 만큼 모니터의 DPI 너무 다양해졌다. 개발자가 '단 하나의 DPI' 를 기준으로 정하기가 어려운 이유는? (데모) 윈도우 메모장을 통해 다중 모니터의 표현 이해하기 애플은 High DPI 처리가 단순 명확하다. 윈도우는 High DPI를 다루기가 어렵다. 윈도우에서 제공하는 DPI 확대/축소 개발한 윈도우용 앱이 High DPI 를 잘 지원하기 위해서, 개발자가 관여 해야 한다. 델파이의 DPI Awareness 옵션 5가지 (2020.11 현재) Unaware (DPI 인식 안함) System aware (시스템 DPI 반영) Per Monitor (모니터 별 DPI 반영) GDI Scaling (GDI 확대/축소) Per Monitor V2 (모니터 별 DPI 반영 버전 2) (데모) 델파이 프로젝트에서 지정한 DPI Awareness 옵션 별 결과 비교 Unaware System aware Per Monitor GDI Scaling Per Monitor V2 TImageCollection TVirtualImageList (데모) Per Monitor V2 옵션에서 TImageCollection와 TVirtualImageList를 사용하기 Per Monitor V2 옵션에서 UI 콘트롤을 동적으로 생성할 때 알맞게 표현하기 위한 VCL 함수들 (데모) Per Monitor V2 옵션에서, UI 콘트롤을 동적으로 생성할 때 알맞게 표현하기 High DPI 관련 핵심 개념 DPI (Dots Per Inch): 1인치에 들어가는 점(Dot)의 갯수 (역자 주: 점은 LCD모니터, 프린터 등 출력 장치의 물리적인 최소 표현 단위) PPI (Pixels Per Inch): 1인치에 들어가는 픽셀(Pixel)의 갯수 (역자 주: 픽셀은 Pics+Element의 복합어이며, 디지털 이미지를 만들 때 사용되는 논리적인 최소 표현 단위) 아주 오래전부터 “윈도우에서 표준 DPI는 96이다”라고 간주하면 안전했다. 그래픽의 사실 상 표준이었던 픽셀 기반은 VGA 부터 sVGA, XGA…로 이어져 오면서 지켜져왔다. DPI와 해상도(Resolution)가 서로 관련은 있지만, 항상 일치하는 것은 아니다. 지금은 더욱 그렇다. 예전에는, 대체로 차이가 거의 없었다. 얼마전까지는 대체로 모니터가 커지고 해상도가 높아져도, 이때에도 '점'의 크기 즉 DPI는 대체로 그대로 유지되면서 크기만 커졌다. 따라서 , 모니터에서 해상도가 커지는 비율 만큼 '점'의 갯수도 같은 비율로 많아지게 된다. 하지만 최근에는, High DPI 장비가 많아졌다 이제는 개발자가 '단 하나의 DPI' 를 기준으로 잡지 못할 만큼 모니터의 DPI 너무 다양해졌다. 화면 배율 (Display Scale Factor) 예전에는, 96 DPI 가 거의 모든 모니터에서 사실 상 표준으로 지켜졌으므로, 1024, 1440 등 해상도가 커져도 UI 작성에 영향이 없었다. 동일하게 96 DPI 인 경우,해상도가 커지면, 활용할 수 있는 면적이 그만큼 커진다는 점만 고려하면 충분했다. 16 x 16 아이콘을 어느 해상도에서 사용해도 큰 문제는 없었다. 이제는, High DPI 화면인 경우, 화면 요소들이 잘 보이도록하는 조치가 필요하다. 예: 226 DPI인 새 노트북에서는 16 x 16 아이콘은 실제 크기가 3mm이다. 너무 작아서 거의 보이지도 않는다. 스크린 해상도 DPI 해당 물리적 화면 크기 1024 x 769 96 10.7” x 8" 1440 x 900 96 15” x 9”.375 2560 x 1440 109 23.4” x 13.2” 3074 x 1920 226 (훨씬 높다) 13.6” x 8.”5 (얼마전에 구입한 노트북) 표1. 얼마 전에 구입한 노트북이 경우, 물리적인 화면의 크기는 더 작은데 DPI는 훨씬 높다. 개발자가 '단 하나의 DPI' 를 기준으로 정하기가 어려운 이유는? 여러 모니터를 동시에 사용하고, 각 모니터의 해상도가 다양해졌다. 사용자가 사용 중인 앱을 드래그하여 DPI가 다른 모니터로 옮기기도 한다. 이제는 다중 모니터 사용에 거의 제한이 없다. (오래 전의 윈도우는 미리 정의된 해상도에 맞는 모니터만 연결할 수 있었다) 사용자가 노트북이나 태블릿에 외부 모니터를 연결/해제하는 경우가 많다. 사용자가 원격 데스트탑을 통해 앱을 사용하기도 한다. 사용자가 컴퓨터 사용 중에 화면 배율(Display Scale Factor)을 변경하기도 한다. (데모) 윈도우 메모장을 통해 다중 모니터의 표현 이해하기 (비디오 7분 30초부터 보기) 윈도우 메모장의 250% 배율 화면: 메인 메뉴 사이의 간격이 매우 좁다. 윈도우 메모장의 일반 배율(100%) 화면 DPI, 해상도, 배율이 다른 모니터를 모두 잘 지원하기는 쉽지 않다. 윈도우 메모장을 보면, High DPI를 전반적으로 무난하게 지원하고 있다. 앱은 배율에 맞게 확대되면서도, 화면이 선명하고, 글자 폰트도 선명하다. 하지만, High DPI에서 여백도 다르고, 본문의 문장의 길이도 다르다. 무엇보다 메인 메뉴 간의 간격이 좁아져서 사용하기에 살짝 불편하다. High DPI에서 윈도우 앱은 "폰트" 확대/축소도 완벽하게 지원하기가 힘들다. "이미지"는 더욱 다루기가 어렵다. 애플은 High DPI 처리가 단순 명확하다. 애플은 모든 화면 요소에서 물리적 표현 단위인 "포인트"를 사용한다. 맥 OS와 iOS에서 PPI는 Point Per Inch를 의미한다. (Pixel Per Inch가 아니다) 애플의 표준은 1인치 당 72 포인트이고, 잘 지켜지고 있다. 따라서, 모니터에 맞게 확대/축소 시, 단순히 배율을 적용한다. 역사적 배경 그래픽 인쇄 분야에서는 DPI (인치당 표현되는 물리적인 점)이 중요하다. 애플은 오래 전부터 이 분야에서 독보적이었다. 윈도우는 High DPI를 다루기가 어렵다. (비디오 11분 47초부터 보기) 마이크로소프트는 애플과 달리 논리적인 단위인 "픽셀"을 사용한다. Dialog Unit (DLU) 마이크로소프트가 고안한 단위로써, 여러 디스플레이 장비를 다룰 수 있도록 윈도우를 설계하는 과정에 생겨났다. 1 Dialog Unit = 윈도우 시스템 폰트 너비 평균의 1/4 Dialog Unit는 논리적인 단위이므로, 물리적인 장비에 따라 달라진다. (장비 의존성이 없고, 물리적 면적에 맵핑되지 않는다) 수직 Dialog Unit와 수평 Dialog Unit가 일치하지 않을 수도 있다. 문제는 지금은 아무도 더이상 Dialog Unit을 사용하지 않는다는 점이다. 마이크로소프트의 개발도구 역시 마찬가지로, 닷넷, 윈폼, XAML 에서도 Dialog Unit을 사용하지 않는다. 요즘 개발도구는 대부분 픽셀(Pixel)을 사용한다. (마이크로소프트 개발도구도 마찬가지이다.) 픽셀은 논리적 단위이며, 물리적 크기가 고정되어있지 않다. 예전에는 거의 모든 모니터가 96 DPI 를 사용했다. 물리적인 단위가 변하지 않으므로, 그것에 기반한 논리적인 단위인 픽셀 역시 실제로 물리적 크기가 고정된 것과 같았다. 이제는 댜양한 DPI가 사용된다. High DPI인 4K 모니터와 일반 모니터는 물리적인 단위인 DPI가 다르기 때문에 그것에 기반한 픽셀의 물리적인 실제 크기 역시 서로 다르다. 윈도우에서는 논리적 크기인 픽셀과 화면의 물리적인 실제 크기를 연결할 방법이 있어야만, High DPI를 다룰 수 있다. 윈도우에서 제공하는 DPI 확대/축소 윈도우는 우리가 아무 조치를 하지 않아도 High DPI 화면에 알아서 표현한다. 윈도우 메모장 데모에서 본 것 처럼 꽤 괜찮지만 여전히 완벽하지는 않다. 개발한 윈도우용 앱이 High DPI 를 잘 지원하기 위해서, 개발자가 관여 해야 한다. 픽셀 크기의 기준을 정하고, 윈도우10 에서 제공하는 DPI 배율 확대/축소(Scaling) 기능을 활용하자. 윈도우는 최신 버전으로 오면서 High DPI 지원이 점점 좋아졌고, 윈도우10에서 상당히 향상되었다. 개발자는 DPI 인식 방식을 각 앱 별로 매니페스트(Manifest)에 기록하여 윈도우에게 알려줄 수 있다. 델파이의 DPI Awareness 옵션 5가지 (2020.11 현재) (비디오 18분 17초부터 보기) 위치: 델파이에서 Project > Options > Application > Manifest > DPI Awareness 옵션 Unaware (DPI 인식 안함) 방식: 윈도우 비트맵은 가장 일반적인 96 dpi를 기준으로 각 모니터에 맞게 확대/축소하여 렌더링한다. 장점 모든 화면 요소를 단순하게 확대/축소하므로, 요소의 위치나 크기가 잘못되지 않는다. 단점 화면이 선명하지 않다. 특히 해상도 낮은 이미지를 High DPI 모니터에서 보면 픽셀이 그대로 드러난다. 의견: 무난한 선택이지만, 보기에 좋지 않기 때문에 최고의 선택은 아니다. (데모 보기) System aware (시스템 DPI 반영) 방식:사용자가 윈도우를 시작할 때 로그인한 모니터의 DPI를 사용하여 윈도우가 알아서 확대/축소하여 렌더링한다. 장점: (언급되지 않음) 단점 사용자가 윈도우를 시작한 주 모니터에 따라, 렌더링 기준이 달라진다. 사용자가 폼을 다른 모니터로 옮기거나 화면 배율(확대/축소)을 변경하면, 화면이 그다지 좋지 않다. 의견: 권장하기 어렵다. (데모 보기) Per Monitor (모니터 별 DPI 반영) 방식: DPI 변경을 최상위 창에 공지하여 DPI가 다른 모니터에서 앱을 따로 다룰 수 있도록 한다. 마이크로소프트가 윈도우8.1부터 채택했다 장점: 윈도우가 모든 것을 임의로 확대/축소하지 않게 되었다. 단점: 실제로는 잘 지원하지 못하고 화면이 틀어진다. (뒤에서 살펴보겠다) 의견: 특별한 이유가 없다면, 사용하지 않는 것이 좋다. (데모 보기) GDI Scaling (GDI 확대/축소) 델파이 10.4에서 VCL용으로 추가되었다. (10.3에서도 가능하긴 했지만 사용하기 불편했다) 윈도우 10 Creators 업데이트 (1703)에서 도입된 기술이 반영된 것이다. 방식: 폰트와 기본 도형 등 모든 것을 GDI 프레임워크가 알아서 DPI에 맞게 확대/축소한다. 디스플레이 배율값과 동일하게 오브젝트를 확대/축소한다. 모니터에 맞게, GDI가 알아서 알맞은 폰트를 사용한다. 원래 10pt인 폰트에 만약 @200% 텍스트가 적용되면, 렌더링할 때 GDI는 실제로 20pt 폰트를 사용한다. 장점 이미지을 제외한 모든 화면 요소를 GDI가 알아서 깔끔하게 표현한다. 개발자가 가장 쉽고 빠르게 High DPI를 잘 지원하는 앱을 만들 수 있다. 단점 개발자가 각 앱별로 별도의 매니페스트를 변경/배포해야 한다. 한 단어 안에서 글자 간격이 불규칙하고 글자가 너무 가깝게 겹칠 수도 있다. 폰트를 잘 선택하여 해결할 수도 있다. 아이콘 등 이미지는 단순히 늘어나거나 줄어들기 때문에 High DPI에서 깨끗하게 표현되지 못한다. 개발자가 관여할 여지가 전혀 없으므로, High DPI 이슈를 개발자가 해소하지 못한다. 의견: 이미지에 색상이나 곡선이 많지 않거나 위의 단점이 문제 되지 않는다면, 최고는 아니지만 대안이 될 수 있다. (데모 보기) Per Monitor V2 (모니터 별 DPI 반영 버전 2) 델파이 10.4부터 제공된다. (역자 주: 델파이 10.3 에도 이 옵션이 있었다) GDI Scaling과 마찬가지로, 윈도우10 Creators 업데이트 (1703) 이후 버전에서 작동한다. 방식 자동 스케일링을 통해 해당 DPI에 맞게 이미지를 제외하고, 모든 것이 확대/축소된다. 또한, DPI 변경을 최상위 창에 공지하여 DPI가 다른 모니터에서 앱을 따로 다룰 수 있도록 한다. 장점: 앱에서 DPI 변경을 인지할 수 있어서, 개발자가 미리 대응할 수 있다. 자동으로 테마가 그리는 윈도우 비트맵은 모두 DPI에 맞게 확대/축소 된다. 비클라이언트 (NonClient) 영역까지도 해당된다. 체크 박스, 라디오 버튼등 공통 콘트롤, 파일 찾기, 폰트 설정 등 윈도우 대화상자 모두가 해당된다. 의견: High DPI를 가장 잘 다룰 수 있는 선택이다. (데모 보기) (데모) 델파이 프로젝트에서 지정한 DPI Awareness 옵션 별 결과 비교 Unaware (비디오 25분 40초부터 보기) High DPI 모니터 실제로 High DPI를 활용하지는 못한다. 앱에서는 폼의 크기는 425 x 405로 인식하고, 폼 전체가 배율에 맞게 단순하게 늘어난다. 모든 요소가 제자리에 있고, 모든 것이 일반 모니터에서와 동일하게 작동한다. 하지만, 폼 전체의 표현이 깔끔하지 않고, 글자와 이미지 곡선에서는 픽셀이 드러난다. 일반 모니터 (96 DPI) ( Unaware 설명 보기) System aware (비디오 28분 15초부터 보기) High DPI 모니터 (사용자가 윈도우 로그인을 한 주 모니터) 아이콘 이미지가 매우 작다 (High DPI에서도 여전히 16x16 크기로 표현되기 때문) 폰트 등 화면 요소들이 선명하게 표현되지는 않는다. 폼 크기는 1055x1002로 High DPI를 활용한다. 일반 모니터 (96 DPI) 96 DPI 모니터에서도 폼 크기는 1055x1002이다. 주모니터인 High DPI를 기준으로 96 DPI와 차이만큼 그대로 축소된다. 그 결과, 모든 것이 크기도 작아지고 선명하지 않다. (System aware 설명 보기) Per Monitor (비디오 30분 01초부터 보기) High DPI 모니터 High DPI에서 폰트 등 화면 요소들이 훨씬 깔끔하게 표현된다. 아이콘 이미지가 매우 작다 (High DPI에서도 여전히 16x16 크기로 표현된다) 폼 크기는 1055x1002로 High DPI를 활용한다. 일반 모니터 (96 DPI) HighDPI에서 잘 보이던 요소들이 96 DPI에서는 크기와 위치가 가 알맞게 적용되지 않는다. 스크롤 바 크기가 훨씬 굵어졌다. 체크 박스와 라디오 버튼 윗부분이 잘렸다. 툴바의 아이콘 간격이 틀어졌다. 이유는, DPI 변경을 앱의 폼에게 전달하지 못하기 때문이다. 스크롤 바와 같은 윈도우 공통 콘트롤에서도 변경전의 DPI를 그대로 반영된다. (Per Monitor 설명 보기) GDI Scaling (비디오 32분 11초부터 보기) High DPI 모니터 개발자가 앱이 GDI Scaling을 사용하도록 별도로 매니페스트를 변경/배포 함으로써, 가장 쉽고 빠르게 GDI를 지원할 수 있으므로 최고는 아니지만 대안이 될 수 있다. 폼은 자신의 크기가 425x405인 줄 알고 있다. 즉 96 DPI 인 줄 안다. 하지만, GDI가 알아서 모든 화면 요소를 High DPI에서 선명하게 표현한다. 폰트, 메뉴간의 간격, 윈도우 콘트롤 등 (단, 이미지는 제외) 폰트는 배율에 맞게 더 큰 폰트가 적용되어서 깨끗하게 표현된다. 아이콘 이미지가 선명하지 않다. (여기서는 아이콘의 16x16 이미지를 단순히 늘렸다) 이미지에 색상이나 곡선이 많지 않은 앱이라면 보기 좋지 않을 수 있다. 일반 모니터 (96 DPI) GDI Scaling은 완벽하지 않지만 멀티 모니터를 대체로 잘 지원한다. (GDI Scaling 설명 보기) Per Monitor V2 (비디오 35분 04초 부터 시청) High DPI 모니터 델파이 10.4부터 제공되며, 가장 완벽하게 High DPI를 지원할 수 있는 옵션이다. High DPI에서 화면 요소가 선명하다는 GDI Scaling의 장점을 그대로 가진다. 폰트, 배치, 윈도우 콘트롤 (스크롤 바 등)이 선명하다. 아이콘 이미지가 매우 작다. (High DPI에서도 여전히 16x16 크기로 표현된다) 하지만, 앱이 DPI 변경을 인지할 수 있으므로 해결할 수 있다 (뒤 데모에서 설명) UI 콘트롤을 동적으로 생성할 때에는 제대로 표현되지 않는다. 하지만, 앱이 DPI 변경을 인지할 수 있으므로 해결할 수 있다 (뒤 데모에서 설명) 일반 모니터 (96 DPI) (Per Monitor V2 설명 보기) TImageCollection 서로 다른 해상도를 가진 이미지들을 공유하는 저장소 예: 아이콘 이미지를 16x16, 32x32 등 여러 해상도에 맞게 보관할 수 있다. 비시각적 컴포넌트이므로 어디든지 넣고 공유할 수 있다. 데이터 모듈이나 메인 폼 등 원하는 곳에 올려두고 쓸 수 있다. 명명 규칙을 맞추어서 이미지 이름을 정하면, 알맞은 이미지가 자동으로 로딩된다. Size in the file name 옵션이 선택되어 있는 지 확인할 것 (ImageCollection 에디터) 다음 3가지 구분자 중 한가지 사용 가능 (-, _, @) 파일명 예시: File-Open-16.png , Edit-Paste-48.png TVirtualImageList 해당 폼의 DPI를 파악하여 각 폼에서 알맞은 이미지를 TImageCollection에서 가져와서 사용하도록 한다. 각 폼마다 각자 TVirtualImageList를 가지고 있어야 한다. 데이터 모듈이나 메인폼에 올려두고 공유하여 다른 폼에서 사용할 수는 없다. 각 폼은 다른 모니터에서 표현될 수 있고, 모니터에 따라 DPI가 다르게 적용될 수 있기 때문이다. AutoFill 프로퍼티 AutoFill을 True로 지정하면, TImageCollection 안의 모든 이미지 중에서 알맞은 것을 TVirtualImageList로 가져온다. 만약, TVirtualImageList에서 TImageCollection 안의 이미지 중 몇가지만 사용하고 싶으면, AutoFill을 False로 지정하고, 원하는 이미지만 선택할 수 있다. (데모) Per Monitor V2 옵션에서 TImageCollection와 TVirtualImageList를 사용하기 (영문 비디오 42분 01초부터 보기) 한국어 더빙 비디오에서 이부분 부터 재생되는 비디오 Per Monitor V2 옵션에서 UI 콘트롤을 동적으로 생성할 때 알맞게 표현하기 위한 VCL 함수들 VCL의 새 함수(들) 단, (윈도우 10 최근 버전의 API를 활용하므로) 윈도우 10 최근 버전 이후에서 만 작동한다. Vcl.Controls.GetSystemMetricsForWindow() 윈도우에 새로 추가된 API인 GetSystemMetrics()와 GetSystemMetricsForDPI()를 호출한다. 이전 버전에서 호출을 시도해도 안전하다. TControl.GetSystemMetrics() 개발자가 편하게 사용하도록 VCL에서 TControl에 GetSystemMetrics가 추가되었다. (DPI 확인은 대체로 콘트롤에서 필요하기 때문이다) 폼 등 모든 TControl이 GetSystemMetricsForWindow 를 호출할 수 있다. 혹시, 이미 윈도우 API에서 직접 GetSystemMetrics를 사용한 코드가 있다면, WinAPI.Windows.GetSystemMetrics로 변경하여 기존 유닛을 그대로 사용해도 된다. TControl.CurrentPPI 프로퍼티 (데모) Per Monitor V2 옵션에서, UI 콘트롤을 동적으로 생성할 때 알맞게 표현하기 (영문 비디오 50분 49초부터 보기) 한국어 더빙 비디오에서 이부분 부터 재생되는 비디오 // 처음 한번 알맞은 크기와 위치에 동적으로 생성되고나면, DPI가 다른 화면에서 표현될 때에도 알맞게 표현된다. procedure TFrmMain.btnAddClick(Sender: TObject); var X, Y, W, H: Integer; begin B := TButton.Create( Self ); B.Parent := pnlPreview; // (변경 전, 10 pixel로 지정) // X := 10; // (변경 후) // VCL.Controls 유닛에 있는 TControl.CurrentPPI 프로퍼티를 사용하여 해당 PPI를 가져와서, // 96 DPI일 때 10 pixel을 기준으로 하고, MulDiv 함수를 사용하여 해당 PPI에 맞게 다시 지정한다. // (참고: Muldiv는 앞의 두 숫자를 곱하고 이어서 세번째 숫자로 나눈 후에 Integer로 반올림하는 델파이 함수) // 일단 이렇게 생성되고 나면, 다른 콘트롤과 마찬가지로 DPI가 다른 모니터로 옮겨져도 알맞게 맞추어진다. X := MulDiv ( 10, CurrentPPI, 96 ); // = 10 * CurrentPPI / 96 Y := MulDiv ( 10, CurrentPPI, 96 ); W := MulDiv ( 75, CurrentPPI, 96 ); H := MulDiv ( 25, CurrentPPI, 96 ); B.SetBounds( X, Y, W, H ); end; Per Monitor V2 매니페스트와 추가된 API를 사용하여 High DPI에서 완벽하게 표현된 결과. end. << DelphiCon 2020 목록으로 이동
  8. << DelphiCon 2020 목록으로 이동 DelphiCon 의 2020 시리즈 중, Leveraging High DPI in VCL Applications - Ray Konopka 의 한글 요약본입니다. 발표자 (Ray Konopka)는 CodeSite, Konopka Signature VCL로 유명한 Raize Software의 창업자이며, 월트 디즈니 어트렉션 테크놀러지의 수석 소프트웨어 엔지니어로서, 디즈니리조트, 디즈니랜드 등의 소프트웨어도 개발합니다. 도서 “델파이 컴포넌트 개발하기(Developing Custom Delphi Component)” 저자이기도 합니다. 델파이는 델파이로 만듭니다. 델파이는 11.0 버전에서 IDE 자체에 HighDPI를 적용하였습니다. 그 결과, 델파이 사용자들이 더 쾌적하게 개발할 수 있게 되었습니다. (모니터가 4K 이상이라면 더욱 효과가 큽니다) 여러분의 앱에서도 델파이 11.0과 같이 서로 다른 다중 모니터 특히 최근에 부쩍 많아진 High DPI 모니터 지원할 수 있습니다. 그 방법을 이 세션에서 설명합니다. 원본 비디오(YouTube) 보기 (54 min)를 권장합니다. 발표 자료도 참고하세요. 목차 High DPI 관련 핵심 개념 이제는 개발자가 '단 하나의 DPI' 를 기준으로 잡지 못할 만큼 모니터의 DPI 너무 다양해졌다. 개발자가 '단 하나의 DPI' 를 기준으로 정하기가 어려운 이유는? (데모) 윈도우 메모장을 통해 다중 모니터의 표현 이해하기 애플은 High DPI 처리가 단순 명확하다. 윈도우는 High DPI를 다루기가 어렵다. 윈도우에서 제공하는 DPI 확대/축소 개발한 윈도우용 앱이 High DPI 를 잘 지원하기 위해서, 개발자가 관여 해야 한다. 델파이의 DPI Awareness 옵션 5가지 (2020.11 현재) Unaware (DPI 인식 안함) System aware (시스템 DPI 반영) Per Monitor (모니터 별 DPI 반영) GDI Scaling (GDI 확대/축소) Per Monitor V2 (모니터 별 DPI 반영 버전 2) (데모) 델파이 프로젝트에서 지정한 DPI Awareness 옵션 별 결과 비교 Unaware System aware Per Monitor GDI Scaling Per Monitor V2 TImageCollection TVirtualImageList (데모) Per Monitor V2 옵션에서 TImageCollection와 TVirtualImageList를 사용하기 Per Monitor V2 옵션에서 UI 콘트롤을 동적으로 생성할 때 알맞게 표현하기 위한 VCL 함수들 (데모) Per Monitor V2 옵션에서, UI 콘트롤을 동적으로 생성할 때 알맞게 표현하기 High DPI 관련 핵심 개념 DPI (Dots Per Inch): 1인치에 들어가는 점(Dot)의 갯수 (역자 주: 점은 LCD모니터, 프린터 등 출력 장치의 물리적인 최소 표현 단위) PPI (Pixels Per Inch): 1인치에 들어가는 픽셀(Pixel)의 갯수 (역자 주: 픽셀은 Pics+Element의 복합어이며, 디지털 이미지를 만들 때 사용되는 논리적인 최소 표현 단위) 아주 오래전부터 “윈도우에서 표준 DPI는 96이다”라고 간주하면 안전했다. 그래픽의 사실 상 표준이었던 픽셀 기반은 VGA 부터 sVGA, XGA…로 이어져 오면서 지켜져왔다. DPI와 해상도(Resolution)가 서로 관련은 있지만, 항상 일치하는 것은 아니다. 지금은 더욱 그렇다. 예전에는, 대체로 차이가 거의 없었다. 얼마전까지는 대체로 모니터가 커지고 해상도가 높아져도, 이때에도 '점'의 크기 즉 DPI는 대체로 그대로 유지되면서 크기만 커졌다. 따라서 , 모니터에서 해상도가 커지는 비율 만큼 '점'의 갯수도 같은 비율로 많아지게 된다. 하지만 최근에는, High DPI 장비가 많아졌다 이제는 개발자가 '단 하나의 DPI' 를 기준으로 잡지 못할 만큼 모니터의 DPI 너무 다양해졌다. 화면 배율 (Display Scale Factor) 예전에는, 96 DPI 가 거의 모든 모니터에서 사실 상 표준으로 지켜졌으므로, 1024, 1440 등 해상도가 커져도 UI 작성에 영향이 없었다. 동일하게 96 DPI 인 경우,해상도가 커지면, 활용할 수 있는 면적이 그만큼 커진다는 점만 고려하면 충분했다. 16 x 16 아이콘을 어느 해상도에서 사용해도 큰 문제는 없었다. 이제는, High DPI 화면인 경우, 화면 요소들이 잘 보이도록하는 조치가 필요하다. 예: 226 DPI인 새 노트북에서는 16 x 16 아이콘은 실제 크기가 3mm이다. 너무 작아서 거의 보이지도 않는다. 스크린 해상도 DPI 해당 물리적 화면 크기 1024 x 769 96 10.7” x 8" 1440 x 900 96 15” x 9”.375 2560 x 1440 109 23.4” x 13.2” 3074 x 1920 226 (훨씬 높다) 13.6” x 8.”5 (얼마전에 구입한 노트북) 표1. 얼마 전에 구입한 노트북이 경우, 물리적인 화면의 크기는 더 작은데 DPI는 훨씬 높다. 개발자가 '단 하나의 DPI' 를 기준으로 정하기가 어려운 이유는? 여러 모니터를 동시에 사용하고, 각 모니터의 해상도가 다양해졌다. 사용자가 사용 중인 앱을 드래그하여 DPI가 다른 모니터로 옮기기도 한다. 이제는 다중 모니터 사용에 거의 제한이 없다. (오래 전의 윈도우는 미리 정의된 해상도에 맞는 모니터만 연결할 수 있었다) 사용자가 노트북이나 태블릿에 외부 모니터를 연결/해제하는 경우가 많다. 사용자가 원격 데스트탑을 통해 앱을 사용하기도 한다. 사용자가 컴퓨터 사용 중에 화면 배율(Display Scale Factor)을 변경하기도 한다. (데모) 윈도우 메모장을 통해 다중 모니터의 표현 이해하기 (비디오 7분 30초부터 보기) 윈도우 메모장의 250% 배율 화면: 메인 메뉴 사이의 간격이 매우 좁다. 윈도우 메모장의 일반 배율(100%) 화면 DPI, 해상도, 배율이 다른 모니터를 모두 잘 지원하기는 쉽지 않다. 윈도우 메모장을 보면, High DPI를 전반적으로 무난하게 지원하고 있다. 앱은 배율에 맞게 확대되면서도, 화면이 선명하고, 글자 폰트도 선명하다. 하지만, High DPI에서 여백도 다르고, 본문의 문장의 길이도 다르다. 무엇보다 메인 메뉴 간의 간격이 좁아져서 사용하기에 살짝 불편하다. High DPI에서 윈도우 앱은 "폰트" 확대/축소도 완벽하게 지원하기가 힘들다. "이미지"는 더욱 다루기가 어렵다. 애플은 High DPI 처리가 단순 명확하다. 애플은 모든 화면 요소에서 물리적 표현 단위인 "포인트"를 사용한다. 맥 OS와 iOS에서 PPI는 Point Per Inch를 의미한다. (Pixel Per Inch가 아니다) 애플의 표준은 1인치 당 72 포인트이고, 잘 지켜지고 있다. 따라서, 모니터에 맞게 확대/축소 시, 단순히 배율을 적용한다. 역사적 배경 그래픽 인쇄 분야에서는 DPI (인치당 표현되는 물리적인 점)이 중요하다. 애플은 오래 전부터 이 분야에서 독보적이었다. 윈도우는 High DPI를 다루기가 어렵다. (비디오 11분 47초부터 보기) 마이크로소프트는 애플과 달리 논리적인 단위인 "픽셀"을 사용한다. Dialog Unit (DLU) 마이크로소프트가 고안한 단위로써, 여러 디스플레이 장비를 다룰 수 있도록 윈도우를 설계하는 과정에 생겨났다. 1 Dialog Unit = 윈도우 시스템 폰트 너비 평균의 1/4 Dialog Unit는 논리적인 단위이므로, 물리적인 장비에 따라 달라진다. (장비 의존성이 없고, 물리적 면적에 맵핑되지 않는다) 수직 Dialog Unit와 수평 Dialog Unit가 일치하지 않을 수도 있다. 문제는 지금은 아무도 더이상 Dialog Unit을 사용하지 않는다는 점이다. 마이크로소프트의 개발도구 역시 마찬가지로, 닷넷, 윈폼, XAML 에서도 Dialog Unit을 사용하지 않는다. 요즘 개발도구는 대부분 픽셀(Pixel)을 사용한다. (마이크로소프트 개발도구도 마찬가지이다.) 픽셀은 논리적 단위이며, 물리적 크기가 고정되어있지 않다. 예전에는 거의 모든 모니터가 96 DPI 를 사용했다. 물리적인 단위가 변하지 않으므로, 그것에 기반한 논리적인 단위인 픽셀 역시 실제로 물리적 크기가 고정된 것과 같았다. 이제는 댜양한 DPI가 사용된다. High DPI인 4K 모니터와 일반 모니터는 물리적인 단위인 DPI가 다르기 때문에 그것에 기반한 픽셀의 물리적인 실제 크기 역시 서로 다르다. 윈도우에서는 논리적 크기인 픽셀과 화면의 물리적인 실제 크기를 연결할 방법이 있어야만, High DPI를 다룰 수 있다. 윈도우에서 제공하는 DPI 확대/축소 윈도우는 우리가 아무 조치를 하지 않아도 High DPI 화면에 알아서 표현한다. 윈도우 메모장 데모에서 본 것 처럼 꽤 괜찮지만 여전히 완벽하지는 않다. 개발한 윈도우용 앱이 High DPI 를 잘 지원하기 위해서, 개발자가 관여 해야 한다. 픽셀 크기의 기준을 정하고, 윈도우10 에서 제공하는 DPI 배율 확대/축소(Scaling) 기능을 활용하자. 윈도우는 최신 버전으로 오면서 High DPI 지원이 점점 좋아졌고, 윈도우10에서 상당히 향상되었다. 개발자는 DPI 인식 방식을 각 앱 별로 매니페스트(Manifest)에 기록하여 윈도우에게 알려줄 수 있다. 델파이의 DPI Awareness 옵션 5가지 (2020.11 현재) (비디오 18분 17초부터 보기) 위치: 델파이에서 Project > Options > Application > Manifest > DPI Awareness 옵션 Unaware (DPI 인식 안함) 방식: 윈도우 비트맵은 가장 일반적인 96 dpi를 기준으로 각 모니터에 맞게 확대/축소하여 렌더링한다. 장점 모든 화면 요소를 단순하게 확대/축소하므로, 요소의 위치나 크기가 잘못되지 않는다. 단점 화면이 선명하지 않다. 특히 해상도 낮은 이미지를 High DPI 모니터에서 보면 픽셀이 그대로 드러난다. 의견: 무난한 선택이지만, 보기에 좋지 않기 때문에 최고의 선택은 아니다. (데모 보기) System aware (시스템 DPI 반영) 방식:사용자가 윈도우를 시작할 때 로그인한 모니터의 DPI를 사용하여 윈도우가 알아서 확대/축소하여 렌더링한다. 장점: (언급되지 않음) 단점 사용자가 윈도우를 시작한 주 모니터에 따라, 렌더링 기준이 달라진다. 사용자가 폼을 다른 모니터로 옮기거나 화면 배율(확대/축소)을 변경하면, 화면이 그다지 좋지 않다. 의견: 권장하기 어렵다. (데모 보기) Per Monitor (모니터 별 DPI 반영) 방식: DPI 변경을 최상위 창에 공지하여 DPI가 다른 모니터에서 앱을 따로 다룰 수 있도록 한다. 마이크로소프트가 윈도우8.1부터 채택했다 장점: 윈도우가 모든 것을 임의로 확대/축소하지 않게 되었다. 단점: 실제로는 잘 지원하지 못하고 화면이 틀어진다. (뒤에서 살펴보겠다) 의견: 특별한 이유가 없다면, 사용하지 않는 것이 좋다. (데모 보기) GDI Scaling (GDI 확대/축소) 델파이 10.4에서 VCL용으로 추가되었다. (10.3에서도 가능하긴 했지만 사용하기 불편했다) 윈도우 10 Creators 업데이트 (1703)에서 도입된 기술이 반영된 것이다. 방식: 폰트와 기본 도형 등 모든 것을 GDI 프레임워크가 알아서 DPI에 맞게 확대/축소한다. 디스플레이 배율값과 동일하게 오브젝트를 확대/축소한다. 모니터에 맞게, GDI가 알아서 알맞은 폰트를 사용한다. 원래 10pt인 폰트에 만약 @200% 텍스트가 적용되면, 렌더링할 때 GDI는 실제로 20pt 폰트를 사용한다. 장점 이미지을 제외한 모든 화면 요소를 GDI가 알아서 깔끔하게 표현한다. 개발자가 가장 쉽고 빠르게 High DPI를 잘 지원하는 앱을 만들 수 있다. 단점 개발자가 각 앱별로 별도의 매니페스트를 변경/배포해야 한다. 한 단어 안에서 글자 간격이 불규칙하고 글자가 너무 가깝게 겹칠 수도 있다. 폰트를 잘 선택하여 해결할 수도 있다. 아이콘 등 이미지는 단순히 늘어나거나 줄어들기 때문에 High DPI에서 깨끗하게 표현되지 못한다. 개발자가 관여할 여지가 전혀 없으므로, High DPI 이슈를 개발자가 해소하지 못한다. 의견: 이미지에 색상이나 곡선이 많지 않거나 위의 단점이 문제 되지 않는다면, 최고는 아니지만 대안이 될 수 있다. (데모 보기) Per Monitor V2 (모니터 별 DPI 반영 버전 2) 델파이 10.4부터 제공된다. (역자 주: 델파이 10.3 에도 이 옵션이 있었다) GDI Scaling과 마찬가지로, 윈도우10 Creators 업데이트 (1703) 이후 버전에서 작동한다. 방식 자동 스케일링을 통해 해당 DPI에 맞게 이미지를 제외하고, 모든 것이 확대/축소된다. 또한, DPI 변경을 최상위 창에 공지하여 DPI가 다른 모니터에서 앱을 따로 다룰 수 있도록 한다. 장점: 앱에서 DPI 변경을 인지할 수 있어서, 개발자가 미리 대응할 수 있다. 자동으로 테마가 그리는 윈도우 비트맵은 모두 DPI에 맞게 확대/축소 된다. 비클라이언트 (NonClient) 영역까지도 해당된다. 체크 박스, 라디오 버튼등 공통 콘트롤, 파일 찾기, 폰트 설정 등 윈도우 대화상자 모두가 해당된다. 의견: High DPI를 가장 잘 다룰 수 있는 선택이다. (데모 보기) (데모) 델파이 프로젝트에서 지정한 DPI Awareness 옵션 별 결과 비교 Unaware (비디오 25분 40초부터 보기) High DPI 모니터 실제로 High DPI를 활용하지는 못한다. 앱에서는 폼의 크기는 425 x 405로 인식하고, 폼 전체가 배율에 맞게 단순하게 늘어난다. 모든 요소가 제자리에 있고, 모든 것이 일반 모니터에서와 동일하게 작동한다. 하지만, 폼 전체의 표현이 깔끔하지 않고, 글자와 이미지 곡선에서는 픽셀이 드러난다. 일반 모니터 (96 DPI) ( Unaware 설명 보기) System aware (비디오 28분 15초부터 보기) High DPI 모니터 (사용자가 윈도우 로그인을 한 주 모니터) 아이콘 이미지가 매우 작다 (High DPI에서도 여전히 16x16 크기로 표현되기 때문) 폰트 등 화면 요소들이 선명하게 표현되지는 않는다. 폼 크기는 1055x1002로 High DPI를 활용한다. 일반 모니터 (96 DPI) 96 DPI 모니터에서도 폼 크기는 1055x1002이다. 주모니터인 High DPI를 기준으로 96 DPI와 차이만큼 그대로 축소된다. 그 결과, 모든 것이 크기도 작아지고 선명하지 않다. (System aware 설명 보기) Per Monitor (비디오 30분 01초부터 보기) High DPI 모니터 High DPI에서 폰트 등 화면 요소들이 훨씬 깔끔하게 표현된다. 아이콘 이미지가 매우 작다 (High DPI에서도 여전히 16x16 크기로 표현된다) 폼 크기는 1055x1002로 High DPI를 활용한다. 일반 모니터 (96 DPI) HighDPI에서 잘 보이던 요소들이 96 DPI에서는 크기와 위치가 가 알맞게 적용되지 않는다. 스크롤 바 크기가 훨씬 굵어졌다. 체크 박스와 라디오 버튼 윗부분이 잘렸다. 툴바의 아이콘 간격이 틀어졌다. 이유는, DPI 변경을 앱의 폼에게 전달하지 못하기 때문이다. 스크롤 바와 같은 윈도우 공통 콘트롤에서도 변경전의 DPI를 그대로 반영된다. (Per Monitor 설명 보기) GDI Scaling (비디오 32분 11초부터 보기) High DPI 모니터 개발자가 앱이 GDI Scaling을 사용하도록 별도로 매니페스트를 변경/배포 함으로써, 가장 쉽고 빠르게 GDI를 지원할 수 있으므로 최고는 아니지만 대안이 될 수 있다. 폼은 자신의 크기가 425x405인 줄 알고 있다. 즉 96 DPI 인 줄 안다. 하지만, GDI가 알아서 모든 화면 요소를 High DPI에서 선명하게 표현한다. 폰트, 메뉴간의 간격, 윈도우 콘트롤 등 (단, 이미지는 제외) 폰트는 배율에 맞게 더 큰 폰트가 적용되어서 깨끗하게 표현된다. 아이콘 이미지가 선명하지 않다. (여기서는 아이콘의 16x16 이미지를 단순히 늘렸다) 이미지에 색상이나 곡선이 많지 않은 앱이라면 보기 좋지 않을 수 있다. 일반 모니터 (96 DPI) GDI Scaling은 완벽하지 않지만 멀티 모니터를 대체로 잘 지원한다. (GDI Scaling 설명 보기) Per Monitor V2 (비디오 35분 04초 부터 시청) High DPI 모니터 델파이 10.4부터 제공되며, 가장 완벽하게 High DPI를 지원할 수 있는 옵션이다. High DPI에서 화면 요소가 선명하다는 GDI Scaling의 장점을 그대로 가진다. 폰트, 배치, 윈도우 콘트롤 (스크롤 바 등)이 선명하다. 아이콘 이미지가 매우 작다. (High DPI에서도 여전히 16x16 크기로 표현된다) 하지만, 앱이 DPI 변경을 인지할 수 있으므로 해결할 수 있다 (뒤 데모에서 설명) UI 콘트롤을 동적으로 생성할 때에는 제대로 표현되지 않는다. 하지만, 앱이 DPI 변경을 인지할 수 있으므로 해결할 수 있다 (뒤 데모에서 설명) 일반 모니터 (96 DPI) (Per Monitor V2 설명 보기) TImageCollection 서로 다른 해상도를 가진 이미지들을 공유하는 저장소 예: 아이콘 이미지를 16x16, 32x32 등 여러 해상도에 맞게 보관할 수 있다. 비시각적 컴포넌트이므로 어디든지 넣고 공유할 수 있다. 데이터 모듈이나 메인 폼 등 원하는 곳에 올려두고 쓸 수 있다. 명명 규칙을 맞추어서 이미지 이름을 정하면, 알맞은 이미지가 자동으로 로딩된다. Size in the file name 옵션이 선택되어 있는 지 확인할 것 (ImageCollection 에디터) 다음 3가지 구분자 중 한가지 사용 가능 (-, _, @) 파일명 예시: File-Open-16.png , Edit-Paste-48.png TVirtualImageList 해당 폼의 DPI를 파악하여 각 폼에서 알맞은 이미지를 TImageCollection에서 가져와서 사용하도록 한다. 각 폼마다 각자 TVirtualImageList를 가지고 있어야 한다. 데이터 모듈이나 메인폼에 올려두고 공유하여 다른 폼에서 사용할 수는 없다. 각 폼은 다른 모니터에서 표현될 수 있고, 모니터에 따라 DPI가 다르게 적용될 수 있기 때문이다. AutoFill 프로퍼티 AutoFill을 True로 지정하면, TImageCollection 안의 모든 이미지 중에서 알맞은 것을 TVirtualImageList로 가져온다. 만약, TVirtualImageList에서 TImageCollection 안의 이미지 중 몇가지만 사용하고 싶으면, AutoFill을 False로 지정하고, 원하는 이미지만 선택할 수 있다. (데모) Per Monitor V2 옵션에서 TImageCollection와 TVirtualImageList를 사용하기 (영문 비디오 42분 01초부터 보기) 한국어 더빙 비디오에서 이부분 부터 재생되는 비디오 Per Monitor V2 옵션에서 UI 콘트롤을 동적으로 생성할 때 알맞게 표현하기 위한 VCL 함수들 VCL의 새 함수(들) 단, (윈도우 10 최근 버전의 API를 활용하므로) 윈도우 10 최근 버전 이후에서 만 작동한다. Vcl.Controls.GetSystemMetricsForWindow() 윈도우에 새로 추가된 API인 GetSystemMetrics()와 GetSystemMetricsForDPI()를 호출한다. 이전 버전에서 호출을 시도해도 안전하다. TControl.GetSystemMetrics() 개발자가 편하게 사용하도록 VCL에서 TControl에 GetSystemMetrics가 추가되었다. (DPI 확인은 대체로 콘트롤에서 필요하기 때문이다) 폼 등 모든 TControl이 GetSystemMetricsForWindow 를 호출할 수 있다. 혹시, 이미 윈도우 API에서 직접 GetSystemMetrics를 사용한 코드가 있다면, WinAPI.Windows.GetSystemMetrics로 변경하여 기존 유닛을 그대로 사용해도 된다. TControl.CurrentPPI 프로퍼티 (데모) Per Monitor V2 옵션에서, UI 콘트롤을 동적으로 생성할 때 알맞게 표현하기 (영문 비디오 50분 49초부터 보기) 한국어 더빙 비디오에서 이부분 부터 재생되는 비디오 // 처음 한번 알맞은 크기와 위치에 동적으로 생성되고나면, DPI가 다른 화면에서 표현될 때에도 알맞게 표현된다. procedure TFrmMain.btnAddClick(Sender: TObject); var X, Y, W, H: Integer; begin B := TButton.Create( Self ); B.Parent := pnlPreview; // (변경 전, 10 pixel로 지정) // X := 10; // (변경 후) // VCL.Controls 유닛에 있는 TControl.CurrentPPI 프로퍼티를 사용하여 해당 PPI를 가져와서, // 96 DPI일 때 10 pixel을 기준으로 하고, MulDiv 함수를 사용하여 해당 PPI에 맞게 다시 지정한다. // (참고: Muldiv는 앞의 두 숫자를 곱하고 이어서 세번째 숫자로 나눈 후에 Integer로 반올림하는 델파이 함수) // 일단 이렇게 생성되고 나면, 다른 콘트롤과 마찬가지로 DPI가 다른 모니터로 옮겨져도 알맞게 맞추어진다. X := MulDiv ( 10, CurrentPPI, 96 ); // = 10 * CurrentPPI / 96 Y := MulDiv ( 10, CurrentPPI, 96 ); W := MulDiv ( 75, CurrentPPI, 96 ); H := MulDiv ( 25, CurrentPPI, 96 ); B.SetBounds( X, Y, W, H ); end; Per Monitor V2 매니페스트와 추가된 API를 사용하여 High DPI에서 완벽하게 표현된 결과. end. << DelphiCon 2020 목록으로 이동 View full 엠바카데로 기술자료
×
×
  • Create New...

중요한 정보

이용약관 개인정보보호정책 이용규칙 이 사이트가 더 잘 작동하기 위해 방문자의 컴퓨터에 쿠키가 배치됩니다. 쿠키 설정 변경에서 원하는 설정을 할 수 있습니다. 변경하지 않으면 쿠키를 허용하는 것으로 이해합니다.