high dpi Per Monitor v2 와 GetSystemMetrics 지원: RAD 스튜디오 10.3

[Kori]

마르코 칸투 (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가 아닌 다른 다중-창 모델 (다중 유동형 창, 도킹 판넬, 탭으로 구성된 창, 등등)으로 전환할 것을 추천한다.