2009-12-12 5 views
9

WPF를 사용하여 응용 프로그램을 개발 중입니다. 앱이 전체 화면으로 실행되며 모니터 해상도에 상관없이 크기를 적절하게 조정해야합니다. 그래픽 디자이너는 UI 버튼, 배경 등의 멋진 이미지를 디자인했습니다. Illustrator 플러그 인을 사용하면 모든 이미지가 xaml 파일로 변환됩니다. 이 모든 이미지를 애플리케이션에 추가 했으므로 멋지게 보입니다. 레이아웃을 유지하면서 화면 크기를 조정할 수 있도록 많은 Grid 레이아웃을 사용하고 있습니다. 이 모든 것이 원하는대로 표시되며, 다른 해상도로 실행될 때 늘어나는 모습은 없습니다. 그러나 화면 전환과 UI 상호 작용이 느립니다.WPF가 내 응용 프로그램이 느린 이유는 무엇입니까?

궁금한 점은 그래픽을 많이 사용했기 때문입니까? 너무 많은 Grid 레이아웃을 사용하고 있습니까? 하지만 해상도가 독립성을 가질 수 있도록 Grid이 필요합니다.

응용 프로그램이 내 개발 컴퓨터에서 제대로 실행되지만 성능이 낮은 컴퓨터에서는 응용 프로그램이 매우 느리게 실행됩니다. 그래, 이건 기대되는 정도지만, 내가 바라는 정도로는 아니야. 제 고용주는 응용 프로그램이 이러한 성능이 낮은 컴퓨터에서 원활하게 실행되어야한다고 주장합니다.

필자는 응용 프로그램의 프로파일 링을 일부 수행했으며, 가장 시간이 많이 걸리는 것은 디스플레이 장치입니다 (그러나 프로파일 러를 얼마나 효과적으로 효과적으로 사용할 수 있는지 잘 모르겠지만).

감속을 유발하는 WPF 인 경우이를 개선하려면 어떻게해야합니까?

+1

실제 답변을 작성하는 데는 충분하지 않지만 illsutrator-to-xaml 플러그인의 출력을 신중히 살펴볼 것입니다. 적어도 자리 표시 자 그래픽 요소 (예 : 빈 그리드)로 앱의 작동 방식을 확인하십시오. – Egor

답변

10

Performance Profiling Tools for WPF을 사용하여 어떤 WPF 활동이 가동 시간을 사용하고 있는지 파악할 수 있습니다. 과도한 그래픽로드로 인해 속도가 느려지는 경우 레이아웃 (예 : 레이아웃)이나 제거 (예 : 비트 맵 효과 (기본 perf killer인데, 나는 편견을 느끼고 싶지 않지만) 귀하의 프로파일 링!)).

6

가 둔화 아마

하지의 원인이되는 WPF 경우)

그것이 둔화의 원인 코드 것을 훨씬 더 가능성이있다. WPF는 강력하지만 PDC 세션에서 this video을 살펴 봐야 WPF 응용 프로그램을 더 빠르게 만드는 방법에 대한 많은 조언을 얻을 수 있습니다.

+0

비디오 링크가 더 이상 작동하지 않습니다. –

+1

이것은 해당 비디오의 현재 위치 인 것으로 보입니다. https://channel9.msdn.com/Events/PDC/PDC09/CL10 – TripleAntigen

2

WPF 성능은 프로세서/메모리보다 더 많은 비디오 카드의 품질에 크게 좌우됩니다. 나쁜 비디오 카드 = 나쁜 WPF 성능.

1

음,이있는 장거리 슛 : 나는 (그리고 WPF를 사용)이보다 매우 빠른충분한 CPU/메모리와 윈도우 2008 서버에서 매우 천천히, 그리고 VSTS 2010를 설치할 때 겸손한 노트북. 우리는 하드웨어 가속을 비활성화 할 수 있었고 그 속도가 빨라졌습니다. 그것은 매우 간단로

아마 당신은이 구성을 시도 하시겠습니까 : Visual Studio 2010 Beta 2 editor performance fix running on a virtual machine

+0

재미 있고, 전에는 WPF 속도를 높이기 위해 DisableHWAcceleration이 사용 된 적이 없었습니다! – itowlson

+0

저도 그렇게 생각했습니다.하지만 VS2010에서 일했습니다. 맹세코 =) http://stackoverflow.com/questions/1743525/can-i-and-how-do-i-target-net-4-with- vs-2008/1743556 # 1743556 –

4
  1. 을 투명 PNG 이미지로 버튼의 당신의 XAML 벡터 이미지 변환합니다. 경로 및 도형은 렌더링, 계산 및 크기 조정에 매우 무겁습니다. 대부분 배포 후에 모양, 크기 또는 기타 특성이 변화하는 애니메이션을 부드럽게 수행하지 않으려면 이미지가 래스터 벡터로 표시되도록 변경하지 않아야합니다.

  2. 그리드는 Canvas, DockPanel과 비교할 때 매우 비용이 많이 드는 레이아웃 관리자입니다. DockPanel을 사용하여 특정 그리드를 때때로 대체 할 수 있다고 생각할 수도 있지만 그렇다고 쉽지 않은 해결 방법이 아니라면 많은 브레인 스토밍이 필요합니다.

  3. 단일 아이가있는 패널을 피하십시오. 시각적 계층 구조를 줄여보십시오.

  4. 버튼과 그와 같은 작은 요소에 고정 된 크기를 더 많이 사용하면 고정 된 크기의 자식을 지정하면 패널에서 레이아웃 처리를 쉽게 할 수 있습니다.

+3

PNG 이미지의 크기가 잘 조정되지 않아 벡터와 함께 사라졌습니다. –

+2

또한, 그리드에 의존하지 않는 한 화면 해상도에 맞게 레이아웃을 조정할 수있는 앱을 어떻게 개발합니까? –

+0

모든 이미지가 PNG로 표시되어야하는 것은 아닙니다 (예 : 모든 아이콘, 버튼 또는 IE의 뒤로/앞으로 버튼과 같음). 크기를 조정하더라도 항상 동일하게 유지되므로 이러한 버튼을 PNG로 변환 할 수 있습니다. 눈금 대신 DockPanel을 사용하거나 "자동"대신 상대적인 열/행 크기를 사용할 수 있습니다. 앱 화면을 조금이라도 보여줄 수 있다면 몇 가지 더 나은 단계를 제안 할 수 있습니다. –

0

일반적으로 WPF는 Windows Forms 및 기본 GDI 또는 DirectX보다 그리기 성능이 훨씬 더 좋지 않습니다.

예, WPF는 GDI에서 지원되지 않는 깔끔한 물건을 만들 수 있다는 의미에서 강력하지만 느립니다.

그리기가 많이 필요하고 느린 하드웨어에서 지원하려는 경우 WPF는 좋은 선택이 아닙니다.

관련 문제