Wir haben eine alte (Win32) und neue (WPF) Version unserer Löschsoftware, die die Händler momentan nebeneinander betreiben. Das Ausführen der WPF-Anwendung verlangsamt jedoch häufig erheblich die Neuzeichnungsrate der Win32-Anwendung.
Ohne die WPF-Anwendung, die ausgeführt wird (oder minimiert), ist die Zeichenrate in der Win32-Anwendung fließend und schnell. Wenn die WPF-Anwendung parallel dazu geöffnet ist, verlangsamt sich die UI-Zeichenrate der Win32-Anwendung merklich. Das Ausführen der WPF-Anwendung scheint die Verwendung einiger Ressourcen auszulösen, die von der Win32-App (beide grafikintensiv) entfernt wurden - was die Geschwindigkeit verlangsamt.
CPU und Speicher sind nicht annähernd gesättigt, also scheint es nichts damit zu tun zu haben. Die Verringerung der Auflösung und / oder die Verringerung der Anzahl der Monitore, die angezeigt werden sollen (wodurch der Speicherverbrauch der Grafikkarte und die Bandbreitenbelastung verringert werden), macht keinen Unterschied. Daher scheint es auch kein Grafikhardware-Leistungsproblem zu sein.
Eine Hypothese, die die Ursache erklären könnte, ist wie folgt:
Unter der Haube wissen wir, dass sowohl die WPF- als auch die Win32-Anwendungen Grafikinformationen an eine "Nachrichtenpumpe" von Windows ausgeben, die im Grunde eine Reihe von Anweisungen zum Zeichnen auf dem Bildschirm darstellt. Es scheint, als wenn die WPF-Anwendung nicht ausgeführt wird, hat der Win32 uneingeschränkten uneingeschränkten Zugriff darauf und Bildschirmaktualisierungen sind flüssig. Wenn Sie die WPF-Anwendung parallel dazu ausführen, werden zusätzliche Nachrichten in diese Warteschlange eingereiht, sodass die Win32-Anwendung härter um Zugriff darauf konkurrieren muss (um jedes Bildschirmelementupdate durchzuführen) und daher die Pumpe "verstopft", was den Effekt ergibt, den wir sehen.
>Wenn das Obige der Fall ist, kann jemand Vorschläge zur Verwaltung / Steuerung der Fenstermeldungspumpe empfehlen, um dies zu verhindern?
Das Flimmern ist der Typ, den Sie normalerweise erhalten, wenn Ressourcen knapp werden, wo Sie einzelne Elemente (Formulare, Beschriftungen) flackern sehen und allmählich auf den Bildschirm zeichnen können.
Wenn jemand irgendwelche Vorschläge / Ideen hat, lass es uns wissen.
Jeder Prozess hat seine eigene Nachrichtenpumpe - diese wird nicht geteilt.
Wenn Sie keine hohe CPU-Auslastung sehen, verwendet WPF Hardwarerendering, sodass möglicherweise eine GPU-Sättigung vorliegt. Kannst du Informationen über die GPU-Nutzung erhalten?
Der folgende Post beschreibt Methoden zur Nutzung der GPU:
Okay, ich denke, wir haben die Ursache gefunden und behoben. Kurz gesagt, hardware- und softwarebeschleunigte Fenster spielen nicht gut. Durch Software-Rendering auf der ganzen Platine werden Fehler behoben, die zuvor bei der Ausführung hardwarebeschleunigter Fenster aufgetreten sind. Da unsere ältere Win32-App bald außer Betrieb genommen wird, ist dies eine praktikable Einschränkung - wir können die Hardwarebeschleunigung einfach wieder einschalten, wenn wir die Legacy-Anwendung löschen.
Hinweise unten:
Es scheint, als ob dieses Problem dadurch verursacht wird, dass eine herkömmliche softwarebeschleunigte 2D-Anwendung (X) und 3D-hardwarebeschleunigte WPF one (Y) gleichzeitig ausgeführt werden, und dies ist ein Grafiktreiberproblem.
Auch das Erzwingen, dass Y im WPF-Software-Beschleunigungsmodus ausgeführt wird, führt zu geringer Verschlechterung der Scrollleistung (da der Engpass immer noch der interne Layoutcode des Rasters ist).
Was es jedoch tut, ist, das langsame Zeichenproblem in X loszuwerden, denn Y läuft jetzt wie alle anderen Windows-Anwendungen auf den Maschinen des Händlers als eine softwarebeschleunigte 2D-Anwendung. Dies erklärt, warum keine anderen Anwendungen als Y eine Verlangsamung verursachten - es scheint, als ob Software- und Hardware-beschleunigte Grafikanwendungen nicht gut laufen, wenn sie gleichzeitig ausgeführt werden.
Das macht Sinn - wenn ich beispielsweise ein hardwarebeschleunigtes Spiel spiele, habe ich Ähnliches gesehen (wobei der Desktop beim Umschalten zwischen Hardware- und Software-Beschleunigungsmodi sehr langsam neu gezeichnet wird).
Glücklicherweise können wir das Hardware-Rendering ohne große Auswirkungen auf die Leistung ausschalten. Sobald X außer Betrieb ist, können wir die Hardwarebeschleunigung für die geringen Vorteile, die es in Y bietet, wieder aktivieren (Unterstützung für glattere Animationen und stärkere Verwendung von Füllgradienten ohne Verlangsamung usw.).
Tags und Links wpf windows performance winapi