Freigeben über

High DPI 추가작업(Discussion about High DPI)

  • Artikel


 

몇 가지 흥미로웠던 논의와 함께, High DPI에 대한 많은 댓글을 달아주셨습니다. 대부분은 우리가 수집해 온 데이터와 일치하는 좋은 예들 입니다. 우리가 데이터를 가지지 않는 분야에 대해서, 이러한 댓글은 우리가 생각하는 많은 가설의 증명이 되었습니다. 새로운 것은 이 기능의 일부 오해가 있고, 또 이 기능에 대한 이상적인 것, 가능한 것, 기능 그 자체에 대한 어떤 「신화」와 같은 부분도 있는 것 같습니다. 이 문서에서는 주로 그런 문제들에 대한 요약과 오해라고 생각되는 부분에 대해의 세부 사항을 제공하고자 합니다. 

다음은 댓글에서 증명된 우리의 「가설」입니다.

  • 대부분의 사람은 문자를 크게 하기 위해 또는 우연히 화면 해상도를 조정한다
  • 일부의 핵심 사용자만이 high DPI를 알고 사용하고 있다
  • 넓은 화면을 좋아하는 사람들이 있고, 또는 큰 UI를 좋아하는 사람들이 있다
  • 일부의 사람은 DPI 설정이 찾기 쉬운 것에 대해서 염려한다
  • 응용 프로그램의 호환성은 큰 문제로, 일부의 사람은 호환성 때문에 이 기능을 이용하지 않는다
  • IE 크기 조정은 가장 큰 문제이다 (IE8을 보시고, 수정된 내용을 확인해 주세요)
  • 여러가지 복잡하고 미묘한 이유로, 이 기능을 다수의 사람들에게 설명하는 것은 어렵습니다.

또, 다음과 같은 의문도 있습니다.

  • 만약 모두가 벡터 기반이라면, 이러한 문제는 모두 해결되는가?
  • 개발자가 아무것도 하지 않아도, 이러한 문제는 해결할 수 없는 것인지?
  • 응용 프로그램에 의한 크기 조정과 IE 확대/축소는 어떻게 다른지?
  • DPI는 조정을 위해 필요한지 그렇지 않으면 크기 조정인가?

몇가지 질문에 대해서는 이미 댓글로 응답했지만, 여기에 대한 관심이 높기 때문에 여기서 세부 사항을 말하겠습니다. 

벡터 그래픽 vs. 래스터그래픽

PC에서 모든 사용자, 개발자, 디자이너의 모든 모든 문제를 단번에 해결하는 「silver bullet」과 같은 기술을 언제나 바라고 있습니다. 그것은 예를 들면, 이 문제에 대한 몇가지 댓글에 있던 것처럼, 만약 OS를 모두 벡터 그래픽을 기초로 하면 이 크기 조정에 관한 문제는 모두 해결된다고 것입니다. 실제로는 모든 것을 벡터 그래픽으로 했을 경우, 몇 가지의 문제가 있습니다.

우선, 아이콘을 작게 했을 때에는 의미를 알기 쉽게 하도록 다른 표현 방법을 사용하는 것이 좋을 경우가 있습니다. 다음의 아이콘들을 봐 주세요.이 경우, 디자이너는 제일 작은 아이콘의 디자인에서는 원근법을 무시한 디자인을 채용하고 있습니다.

image icons_thumb_1

이러한 이유이지만, 가장 작은 아이콘 크기에서는 아이콘에 따라서, 표현하는 정보가 바로 정면에서 그리는 것이 보다 알기 쉽다고 디자이너가 판단했기 때문에입니다. 이 일러스트는 이 점에 관한 또 하나의 예입니다：

XP File Icons_thumb

당연히 디자이너는 여러 버전으로 이미지 디자인을 제작해야 하기 때문에 복잡해집니다. 여기서의 중요한 것은 절충이 필요하고, 한편 그 절충이 반드시 명확해지는 것은 아닙니다. 

만약, 하나의 벡터 기반 디자인을 사용해도 디자이너가 마음에 그린 것을 충실히 나타내기 위해, 크기에 의존한 미세 조정이 필요한 것은 공통입니다. 1픽셀의 선으로 그려진 128 x128 크기의 벡터 이미지를 1/2크기의 64 x64에 축소하는 것을 상상해 보세요. 완벽하게1/2픽셀의 선을 디스플레이로 재현하는 방법은 없습니다! 많은 경우, 이 점에 대한 방법으로서 드로잉 처리는 비슷한 선의 “동그라미”를 실행합니다. 그렇지만, 이 처리를 실시하면, 이미지 이미지의 다른 요소의 레이아웃이 근본적으로 변경됩니다. 또, ”어느 선을 동그라미 처리의 대상으로 할까?” 라는 의문도 있습니다. 디자이너가 원판을 수동 조정하지 않으면, 렌더링 엔진이 그 결정을 실행합니다. 그리고 이것이, 바람직하지 않은 드로잉 결과의 요인이 됩니다. 거기서, 어느 요소를 벡터로 사용해야 하는지 규칙을 정의해야 합니다. 그러나 그것은 표현 가능한 컨셉에 대해 한층 더 제약을 추가할 뿐입니다.

Windows에서 우리가 사용하고 있는 TrueType 폰트조차도 그 드로잉 결과를 가능한 한 고품질로 하기 위해, 크기마다 수동으로 조정을 실시하고 있습니다. TrueType의 렌더링 파이프라인의 대부분은 알고리즘에 근거하여 벡터 소스를 크기 조정 하는 일을 기본으로 하지만, TrueType안에는 크기별 “힌트”가 수동으로 코딩됩니다. 이것은 디자이너가 어느 특정의 드문 경우를 시스템이 어떻게 대처할지를 지시하기 때문입니다 (예를 들면, 픽셀 경계에 있는 선을 어떻게 대처하는지 등 ). 이 점에 관한 보다 세부 사항기술은 여기를 참조하세요：https://blogs.msdn.com/fontblog/archive/2005/10/26/485416.aspx

벡터 이미지가 반드시 보다 작은 크기가 되는 것은 아닙니다(특히 작은 이미지). 대부분의 디자이너는 드로잉이나 이미지 효과용으로 많은 복수 층을 구성하고 이미지를 만들어 내는 편집기를 사용하여 이미지를 제작합니다. 비트맵을 기반으로 한 이미지에서는 디자이너는 그것을 소프트웨어의 일부에 추가하기 전에 미리 층을 “플랫화”합니다. 요즈음 대부분의 디자이너는 층 크기에 대해서 거의 신경을 쓰지 않습니다. 왜냐하면, 플랫화 프로세스에서는 기본적으로는 이미지 해상도에 근거한 고정크기에 변환을 하기 때문입니다. 벡터 이미지에는 이러한 플랫화 기술은 없기 때문에 아이콘이 너무 커지지 않도록 디자이너는 사용하는 도구와 이미지 효과에 대해 신중하게 고려할 필요가 있습니다. 나는 Windows의 비트맵의 디자이너가 가지고 있는 벡터 이미지의 원 데이터를 보았습니다만, 그것은 622 k 였습니다. 물론, 그것은 해상도에 의존하지 않고 같을 파일크기입니다. 그러나, 그 거대한 파일은 23 k의 PNG의 비트맵 이미지에 플랫화 됩니다.

이미지 생성의 공정으로 크기의 제약 사항이 있었다면, 이 수동 조정으로 벡터 기반의 이미지도 작아집니다. 그러나, 그 제약 사항은 디자이너에 대하는 추가 제약 사항이 되었을 것이고, 그 제약 사항에 잘 대처하는 방법을 디자이너가 학습해야 합니다. 

개발자분들을 위해서

레이아웃이나 그래픽을 미묘하게 조절하거나 해상도에 맞추어 이미지의 정확하게 크기 조정 할 필요가 있는 응용 프로그램이 최선의 결과를 내려면 , 아이템의 픽셀 위치를 올바르게 지정하는 것이 중요합니다. 이것은 Mac에서도 PC에서도 변함없습니다(https://developer.apple.com/releasenotes/GraphicsImaging/RN-ResolutionIndependentUI/  참조).적절한 도구나 프레임워크가 제공되면, 그런 걱정은 필요 없을 것이라는 의견도 있습니다. 그러나 이러한 도구 집합이나 프레임워크에는 각각의 절충이 존재하고 있습니다. (그것이 Win32이던 .net이던, HTML이든.) 이렇다 할 특효약은 없습니다만, 개발자가 간단하게 DPI 에 대응한 응용 프로그램을 생성할 수 있도록 도울 수 있습니다. 예를 들어, 가까운 시일내에 중요한 에코시스템 관련 이벤트가 두개 개최되지만, 거기서 High DPI에 대해 자세하게 이야기할 예정입니다. 또, 기존의 응용 프로그램에서 DPI 대응 변환 방법을 개발자가 습득하기 위한 재료도 있습니다. 첫번째 이벤트는 Microsoft Professional Developer Conference입니다. 여기에서는 “Writing your Application to Shine on Modern Graphics Hardware (link)”라고 제목으로 High DPI에 대해 이야기 하고 싶습니다. 두번째 이벤트는 Windows Hardware Engineering Conference입니다. 여기서는 “High Fidelity Graphics and Media”트럭 (link)에서 high DPI 를 취할 예정입니다.

응용 프로그램의 호환성에 대해

응용 프로그램의 호환성과 high DPI 에 관해서, 몇가지 (bluvg 등에서) 댓글이 달렸습니다. 또, High DPI 설정의 복잡함이나 난해함에 대한 의견을 받고 있습니다. 응용 프로그램 상호교환성 문제는 자동 크기 조정 기능을 유효하게 하거나 무효로 하여 해결할 수 있는 경우가 있습니다. 이 기능은 DPI 크기 조정 화면에서 [사용자 지정 DPI (Custom DPI)] 버튼을 클릭하여, [Windows XP 형식의 DPI 크기 조정 사용] 이라는 체크 박스를 체크하거나, 체크하지 않음으로써 변경할 수 있습니다. 이 체크 박스를 체크하지 않으면, DPI 대응이라고 선언하지 않은 응용 프로그램은 자동적으로 윈도우 관리자에 의해서 크기가 조정됩니다. 이 박스가 체크되어 있으면, 자동 크기 조정 기능은 무효화됩니다. DPI 설정 < 144 DPI 의 경우, 이 체크 박스는 초기설정에서 체크되어 있지만, DPI 설정 >= 144 의 경우는 초기설정이 체크되어 있지 않습니다. 사용하고 있는 응용 프로그램이나 DPI 설정에 따라서는 이 초기설정을 변경하는 것으로, 보다 좋은 효과를 얻을 수 있습니다. 또, 자동 크기 조정 기능은 Vista 프로그램의 호환성 속성을 사용해 응용 프로그램 단위로 무효화할 수도 있습니다. 자세한 내용은 여기를 참조해 주세요.

https://windowshelp.microsoft.com/Windows/ko-kr/help/bf416877-c83f-4476-a3da-8ec98dcf5f101042.mspx(“Disable Display Scaling on high DPI settings”의 항을 참조)

DPI크기 조정과 응용 프로그램 크기 조정 (예: IE 확대 기능) 의 차이

일반적인 응용 프로그램 UI는 컨텐츠 윈도우와 프레임 UI로 구성됩니다. 프레임 UI는 메뉴 항목이나 도구 막대 버튼이 있는 바입니다. 컨텐츠 윈도우는 「문서 보기」입니다. 예를 들면, IE의 경우, 컨텐츠 윈도우는 실제의 웹 페이지를 말합니다. 컨텐츠 윈도우에서 High DPI 크기 조정을 지원하는데 필요한 코드는 확대 기능을 구현하는데 필요한 코드와 같습니다. 실제, 컨텐츠 윈도우에 대해서, IE8에서는 High DPI 설정을 사용하여 기본 확대 기능이 구성됩니다. (자세한 내용은 DPI Scaling and Internet Explorer 8을 참조하십시오.) 그러나, high DPI에는 프레임 UI 크기 조정에도 영향을 줍니다. 대부분의 사용자가 텍스트를 크게 하여, 읽기 쉽도록 하기 위해 크기 조정 기능을 사용하고 있으므로, 프레임 UI도 당연히 크기가 조정되어 메뉴 항목이나 도구 막대의 힌트 텍스트 크기가 변경됩니다. 여기에서도 컨텐츠 영역에만 적용되는 응용 프로그램의 크기 조정이 있으면, 응용 프로그램은 그것도 지원합니다. 개발자는 사용자의 요구에 맞춰 개발하기 때문입니다. DPI 크기 조정은 모든 응용 프로그램의 UI 요소가 똑같이 표시되도록 합니다.

DPI는 (“1인치가 1인치”가 되도록) 화면 조정을 목적으로서 사용해서는 안된 것인지?

High DPI는 디스플레이 차이 뿐만 아니라, 개체의 실제 크기가 같아지도록 화면을 조정하기 위해서만 사용해야 한다는 의견도 있었습니다. 논리적으로 말하면 이것은 매우 적합한 말입니다. 이것은 디스플레이를 “an inch is an inch (1 인치는 1 인치로 표시한다)”가 되도록 조정한다는 것입니다. 우리는 이것에 대해 검토했습니다만, 이것으로는 텍스트나 UI의 크기를 설정할 수 있도록 해주기를 원하는 최종 사용자의 요구를 만족시켜 줄 수 없다는 문제에 직면했습니다. 만약 「글로벌 크기 조정」의 변수가 있다면, 응용 프로그램 개발자는 양쪽의 메트릭스를 고려해야 하기 때문입니다. 따라서 개발자의 작업이 복잡해집니다. 또한 만약 사용자가 「UI가 너무 작다」라고 생각했을 경우, 어느 정도 큰 UI로 하면 좋은 것인지는 개발자가 결정하는 것일까요? 그렇지 않으면 사용자일까요? 바꿔 말하면, 만약 설계자가 「이 버튼은 1 인치가 좋다」라고 생각해도 사용자가 「버튼은 1.5 인치로 해야 사용하기 쉽게 하고 싶다」라고 생각하면, 누가 설정을 결정해야 합니다. 오늘의 기능 사용 방법을 생각하면, 자신이 좋아하는 설정으로 할 수 있는 것은 사용자이지만, 사용자 설정이 올바르게 반영되는 것을 확인하는 것은 응용 프로그램 개발자의 책임입니다.

다시 말하면, High DPI에 대해서 높은 관심이 있다는 것을 알게 되어 몹시 기쁩니다. 확실히, 우리가 다뤄야 할 문제들이 있지만, 여러가지 의미에서 에코시스템은 이 변화에 대응할 수 있는 시기에 온 것 같습니다. 이번 문서에 대한 피드백 대해, High DPI 기능의 complex system에 대해 보다 자세한 설명이 되었으면 하는 바램입니다. 

--Ryan Haveson

Comments

  • Anonymous
    January 24, 2009
    벡터 이미지는 작은 사이즈일 때 식별력이 없어서 새로 그렸다