Leistung von DrawingVisual vs Canvas.OnRender für viele sich ständig ändernden Formen

Question

Ich arbeite an einer spielähnlichen App, die bis zu tausend Formen (Ellipsen und Linien) hat, die sich ständig mit 60 fps ändern. Nachdem ich eine excellent article on rendering many moving shapes gelesen habe, habe ich dies mit einem benutzerdefinierten Canvas-Nachkommen implementiert, der OnRender überschreibt, um die Zeichnung über eine DrawingContext zu machen. Die Leistung ist ziemlich vernünftig, obwohl die CPU-Auslastung hoch bleibt.

Allerdings schlägt der Artikel, dass der effizienteste Ansatz für ständig in Bewegung Formen viele DrawingVisual Instanzen verwenden statt OnRender. Leider erklärt es aber nicht warum das für dieses Szenario schneller sein sollte.

Die Implementierung auf diese Weise zu ändern, ist kein kleiner Aufwand, daher würde ich gerne die Gründe und die Frage verstehen, ob sie auf mich anwendbar sind, bevor Sie sich für den Wechsel entscheiden. Warum konnte der Ansatz DrawingVisual in diesem Szenario zu einer geringeren CPU-Auslastung führen als der Ansatz OnRender?

Answer 1

Ich dachte Petzold erklärt in diesem Absatz;

Die ScatterPlotVisual Klasse Werke von ein DrawingVisual Objekt für jedes Datapoint zu schaffen. Wenn sich die Eigenschaften eines DataPoint-Objekts ändern, muss die Klasse nur ändern, um die DrawingVisual , die diesem DataPoint zugeordnet ist, zu ändern.

, die auf einer früher Erklärung baut;

Jedes Mal, wenn die Itemssource-Eigenschaft Änderungen oder die Sammlung Änderungen oder eine Eigenschaft der Datapoint-Objekte in der Sammlung Änderungen, ruft ScatterPlotRender InvalidateVisual. Dies erzeugt einen Aufruf an OnRender, der das gesamte Streudiagramm zeichnet.

Sind Sie gefragt?

Übrigens, this ist ein ziemlich neues Hochleistungs-WPF-Tutorial, viele Zehntausende von Punkten in diesem Plot, es ist 3D gerendert und animiert auch (sogar Mauseingabe verwendet, um einige der Transformationen zu fahren).

Answer 2

Von Pro WPF in C# 2008:

Das durch diese Anwendungen gestellte Problem ist nicht die Komplexität der die Kunst, sondern die schiere Anzahl der einzelner grafischer Elemente. Selbst wenn Sie Ihre Pfadelemente durch leichtere Geometry-Objekte ersetzen, wird der Overhead die Leistung der -Anwendung immer noch beeinträchtigen. Die WPF Lösung für diese Art von Situation ist , um die untere visuelle Ebene Modell zu verwenden. Die Grundidee ist, dass Sie jedes grafische Element als Visual Objekt, das ist eine extrem leichte Zutat, die weniger Overhead als ein Geometry-Objekt oder ein Path-Objekt hat.

Worauf es hinausläuft ist, dass jede einzelne dieser Ellipsen und Linien, die Sie erstellen, eine separate FrameworkElement ist; Das heißt, es unterstützt nicht nur Treffer-Tests, sondern auch Layout, Eingabe, Fokus, Ereignisse, Stile, Datenbindung, Ressourcen und Animation. Das ist ein ziemlich schweres Objekt für das, was Sie zu tun versuchen! Das Objekt Visual überspringt all das und erbt direkt von DependencyObject. Es bietet weiterhin Unterstützung für Hit-Tests, Koordinatentransformationen und Bounding-Box-Berechnungen, aber keine der anderen Dinge, die die Shapes unterstützen. Es ist viel leichter und würde wahrscheinlich Ihre Leistung immens verbessern.

EDIT:

Ok, ich falsch verstehe Ihre Frage zum ersten Mal um.

Wenn Sie OnRender verwenden, hängt es wirklich davon ab, wie Sie die Visuals erstellen und anzeigen. Wenn Sie DrawingContext verwenden und alle visuellen Elemente zu einem einzelnen Element hinzufügen, unterscheidet sich dies nicht von der Verwendung des Ansatzes DrawingVisual. Wenn Sie für jedes erstellte Visual ein separates Element erstellen würden, wäre dies ein Problem. Es scheint mir, dass Sie die Dinge richtig machen.

Answer 3

Jeder in den Antworten hat es falsch verstanden. Die Frage ist, ob das Rendern von Formen direkt im Zeichnungskontext schneller ist als das Erstellen von DrawingVisual. Die Antwort ist offensichtlich "Ja". Funktionen wie DrawLine, DrawEllipse, DrawRectangle usw. erzeugen kein UI-Element. DrawingVisual ist viel langsamer, da es ein leichtgewichtiges UI-Element erstellt. Die Verwirrung in den Antworten ist, weil Leute einfach kopieren/einfügen, das DrawingVisual führt besser als unterschiedliche UIElement Shapes-Anweisung von MSDN.

Answer 4

In meinen Tests jedoch (Schwenkanimationen) bemerke ich keinen Geschwindigkeitsunterschied. Ich würde sagen, dass die Verwendung eines Host-Elements für viele Zeichnungsobjekte etwas schneller ist. Dieser Ansatz, bei dem Sie Ihren visuellen Baum mit vielen visuellen Elementen erstellen, gibt Ihnen mehr Kontrolle. Wenn Sie einen komplexen Hit-Test durchführen möchten, ist der Filterprozess schneller, weil Sie ganze "Zweige" von Visuals überspringen können