"디스플레이 배율 사용 안 함"으로 어떤 버그가 수정 되었습니까?

Question

이제 Windows 10에서 실행해야하는 레거시 응용 프로그램을 상속했습니다. 테스트하는 동안 프로그램의 일부 (도구 모음으로 배치 된 하위 창)가 프로그램 시작시 부분적으로 만 추출된다는 것을 발견했습니다. 절반 이상 툴바 오른쪽의 검은 색 만 그릴 것입니다. 런타임시 전체 윈도우의 크기를 조정하여 도구 막대 윈도우의 크기를 변경하거나 다시 그리는 것이 수정되었습니다. 우리는 결국 "Disable display scaling"을 설정하면 버그를 완전히 막을 수있는 것으로 나타났습니다 (지금까지 10,000 개가 넘는 자신감을 테스트 한 결과 나에게 충분 함).

질문 :

이 문제를 유일한 가능성 I가 버그 185 개 기회 관련된 프로그램의 자동 테스트 우리의 영상으로부터 결정된 1/12 및 1/20 (사이의 확률로 발생 발생 패턴은 식별되지 않음). 나는 이런 버그를 다룰 필요가 없었기 때문에, 버그의 명백한 무작위성과 수정 사항을보고 무슨 일이 일어 났는지 궁금합니다. Windows에서 "높은 DPI"를 위해 업 스케일링 한 비트 맵 렌더링과 툴바를 배치하는 기능 간의 경쟁 조건은 무엇입니까?

Answer 1

Windows 10은 DPI 인식의 개념을 확장했습니다. 이전에는 DPI 인식이 프로세스 별 설정 이었지만 이제는 스레드 별 개념입니다. MSDN docs 문구는 이제 조금 해독하기가 어렵지만 SetProcessDPIAwareness (레거시 앱이 수행 할 것으로 예상되는)를 호출하는 것이 (프로세스에 이름이 있음에도 불구하고) 호출하는 스레드에만 영향을 미친 것처럼 들립니다.

이론 # 1 : 아마도 툴바 창이 DPI 인식 기능이있는 스레드에서 만들어 지기도하고 때로는 다른 스레드에서 만들어지는 경우가 있습니다.

이론 # 2 : SetProcessDPIAware를 호출하는 앱과 나중에 도구 모음 창을 그리는 데 사용되는 표시 메트릭을 캐싱하는 일부 UI 코드 사이에는 경쟁이 있습니다. 경주에서이긴 사람에 따라 올바르지 않은 행동을하게 될 수도 있습니다.

이전 응용 프로그램 (예 : 기존 응용 프로그램)이 매니페스트 설정을 사용하여 전체 프로세스에 대해 DPI 인식을 설정하는 것이 좋습니다. 이 설정은 프로세스의 모든 스레드에 적용되도록하고 모든 사용자 코드가 실행되기 전에 발생해야하므로 인종이 없어야합니다. 스케일링을 비활성화하면 문제를 해결하는 것으로 보이고 DPI 인식을 설정하는 것은 사실상 그와 비슷해야합니다. 이론이 맞으면 문제를 해결할 수있을 것으로 기대합니다.

documentation for SetProcessDpiAware은 매니페스트와 함께 DPI 인식을 설정하는 방법을 설명합니다.