저는 XNA/WinForms를 기반으로하는 기존 타일 맵 편집기를 WPF로 마이그레이션하는 작업을하고 있습니다. 저는 WPF에 익숙하지 않지만 개념의 대부분은 파악하기가 어렵지 않았습니다. Viewbox에서 파생 된 DrawingContext의 DrawImage 메서드를 사용하여 ScrollViewer에 포함 된 Viewbox를 OnRender 메서드에서 파생시켜지도를 그립니다. 문제는 XNA/WinForm 버전과 비슷한 성능을 보이는 곳이라면 화면에 많은 양의 타일이있을 때 얻을 수 없다는 것입니다. 확대/축소 및 패닝을 구현했지만 너무 많이 축소하거나 화면에 많은 양의 타일이있는 경우에는 사용자 경험을 망칠 주요 지연이 있습니다. 몇 가지 분명한 최적화 조치 (소스 비트 맵 고정, 볼 수없는 타일 제거, 비트율 조정 모드를 LowQuality로 설정, 캐시 캐싱 힌트 제공)를 수행했지만 문제를 해결하지 못하는 것 같습니다. 이 문제는 WPF가 DrawingContext를 사용하여 텍스처 쿼드를 그리는 방식에서 분명히 나타납니다.WPF 슬로우 타일 맵 렌더링 성능
SampleGridDrawingExample이 마우스 가운데 버튼을 누른 상태에서 이동하려면 마우스를 이동 :
나는 문제를 재현하는 데 필요한 모든 코드와 예제 응용 프로그램을 제공하고 있습니다. 창의 크기가 커질수록 더 많은 눈에 띄게됩니다 (분명히 더 많은 타일이 렌더링되기 때문입니다).
WPF 내에 DrawingContext보다 빠른 방법으로 많은 양의 텍스처가있는 합리적인 성능의 쿼드를 그립니다. XNA/WinForms를 사용하면 합리적인 지연으로 여러 레이어에서 ~ 50000 개의 타일을 그릴 수 있습니다. WPF에서는 현재 접근 방식을 사용하여 1000 이상의 눈에 띄는 지연 (> 10000이 응용 프로그램을 크롤링 함)을 유발합니다.
마우스 이동 중 계산은 단순히 마우스 델타를 계산하고 마우스 델타를 기반으로지도를 스크롤하는 것입니다. 난 그게 문제가되지 않을 것이라고 생각하지만 (분명히 내가 CPU를 점프 이해하므로 마우스를 움직일 때이 계산 자주.) 이전 편집기는로드 된 비트 맵을 Texture2D로 변환하고 렌더링 (SpriteBatch 사용)하기 위해 XNA 만 사용합니다. 거기에지도를 그리는 루프는 샘플과 같습니다. 그래서 본질적으로 GPU가 처리하지만, 도용 및 확대/축소를위한 입력에 반응하기 위해 보이는 영역을 계산하는 데 관련된 일부 CPU가 있습니다. – batchprogram
WPF가 샘플에서 하드웨어 가속을 사용한다고 가정 할 때 이전 편집기와의 렌더링에서 유일한 차이점은 이전 편집기에서 응용 프로그램 Idle 이벤트와 연결되는 루프가 있다는 것입니다.이 이벤트는 다음과 같은 속도로 맵을 다시 그립니다. 60Hz. – batchprogram