spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Hallo Leute,

ich schreibe zurzeit ein Programm für Lichtsteuerung über DMX. Ich schreibe mir ein eigenes, weil ich ein Bedienungskonzept verfolge, das mir die auf dem Markt erhältlichen nicht zufriedenstellend bieten können. Klassendiagramm und Hard/Softwareverbindung zum DMX-Interface und damit meinen Lampen steht schon.

Ausschnitt aus meinem Klassendiagramm: Die höchste Klasse ist die Effektklasse (Lauflicht etc.), diese steuert die Funktionen (Farbe, Position) der Geräte (Dimmerpack, Moving-Head), die dann die Kanäle (0, 1, 2, ... , 512) im DMX-Interface aktualisieren.
Die Effektklasse wird von einem Timer aktualisiert, das bewirkt eine Kaskade von Methodenaufrufen, die letztendlich die DMX-Werte im Interface neu setzen. Das Ganze funktioniert auch schon wie gewollt schön schnell. Nun möchte ich eine GUI programmieren, die dem User die aktuellen Effekt-Zustände und Funktionswerte anzeigen. Eine OneWay-Bindung reich dazu aus.

Jetzt meine Frage: Wie soll mein Quellobjekt aussehen, damit auf keinen Fall die "Hintergrund-Kaskade" gebremst wird - eher soll die GUI langsamer geupdated werden! Zur Option stehen DependencyObject, INotifyPropertyChanged, das Updaten der Steuerelement-Eigenschaften mit Methodenaufrufen von der Kaskade aus und das Updaten der Eigenschaften z.B. jede 100ms durch einen Timer, der dann auch die Steuerelement-Eigenschaften manuell setzt. Wenn es noch andere (bessere) Möglichkeiten gibt: Immer heraus damit!

Argumente für DependencyObject:
+ schnelles updaten der Bindung
+ wenig Speicherverbrauch
+ Man kann Animationen drauf anwenden
- Klasse muss von DependencyObject erben
- Abhängigkeit von WPF - portieren schwierig

Argumente für INotifyPropertyChanged:
+ keine Abhängigkeiten, sondern einfaches Event-System
+ "nur" eine Schnittstelle muss vererbt werden
- viel Speicherverbrauch (warum eigentlich?)
- langsames updaten der Bindung

Argumente für ein kaskadengesteuertes updaten der Eigenschaften (Bsp: Content, Text) direkt:
+ sehr kurzer Code
+ hohe Performance (Stimmt das?)
- Man muss das Updatesystem selber verwalten

Argumente für ein timergesteuertes updaten der Eigenschaften:
+ Die Kontrolle über die Häufigkeit der Updates liegt beim Programmierer
+ Damit kann die benötigte Leistung gut Kontrolliert bzw. eingeschrenkt werden

Wenn ich die Argumente so vergleiche, dann fliegt INotifyPropertyChanged ja leistungstechnisch sofort raus. Allerdings fehlen mir die Benchmarks (nennt man das so? ) für die Rechenpower die diese 4 Möglichkeiten benötigen, denn ich will ja nicht so die Leistung für die Datenbindung verbrauchen, sondern eher für meine Methodenkaskade, die mein DMX-Interface updatet!

Ich hoffe, einer von euch ist so mutig, kämpft sich durch meinen Text durch und kommt bei diesem Satz an...

Danke für eure Mühe und dann hoffentlich konstruktive Vorschläge!

Schonmal vielen Dank für eure hilfreichen Antworten!

@QuickAndDirty: Ja, ich habe das MVVM-Pattern wie es beschrieben ist, implementiert. Ich trenne zwischen den WPF-Controls und meinen Hintergrundklassen. Allerdings habe ich nur eine Zweiteilung und keine Dreiteilung - das ViewModel in der "Mitte" fehlt bei mir. Ist das schlimm? Zu den 100 ms: Das ist die minimale Bildrate, die ich erwarte. Die Kaskade wird sehr viel häufiger ausgelöst - so 100 mal pro Sekunde pro Effekt. Und wenn dann 20 gleichzeitig laufen, dann ist das doch schon eine ganze Menge oder?

@Sacaldur: Mein Klassendiagramm ist ein bisschen unvollständig - die Effekte können nämlich beliebig parametrisiert werden, dann können Effekte auch andere Effekte steuern. Das kann dann ganz schnell zu finde ich sehr vielen Berechnungen kommen.

Mir gings jetzt nicht hauptsächlich um die Performance der Bindung an sich, sondern die Rechenleistung, die mir dadurch dann nicht mehr für die Kaskade zur Verfügung steht... Genau dazu finde ich ja nichts im INET. Zur Bindungsperformance selber gibts ja ne Menge, wie angemerkt wurde.

Ich denke, dass ich mich für INotifyPropertyChanged entscheide, weil das finde ich kleiner ist und mich die Vererbung von einem DependencyObject stört! Und um Animationen nutzen zu können, kann ich ja immernoch in einer Effektklasse DependencyProperties einsetzen.

@BlueCobold & Sacaldur: Ich versuche mal Licht ins Dunkel zu bringen: Die Eigenschaften meiner Klassen, die ich in WPF anzeigen möchte, habe ich jetzt mit "INotifyPropertyChanged-Logik" versehen. Die GUI enthält im Code-Behind eine ObservableCollection, mit mehreren Klassenobjekten. In XAML programmiere ich dann DataTemplates, die die Klassen anzeigen können, indem sie Steuerelemente mit {Binding Path=PropertyName} an meine Klasse binden. Dann binde ich ein ItemsControl an die ObservableCollection, dass mir die Klassen dann anzeigt. So habe ich MVVM verstanden!?

Sorry, wenn mein

Zitat von »Sacaldur«

Ich trenne zwischen den WPF-Controls und meinen Hintergrundklassen.

ein bisschen irreführend formuliert war...

Ich probiere es jetzt einfach mal aus, wie gut das Ganze mit INPC funktioniert. Danke für eure Ratschläge!

Zitat von »Legend«

Was? Höchstens bei nem Minibeispiel. Wenn du ein größeres Projekt hast schreibst du entweder eine Methode die alles updated (langsam) oder dein Code wird schnell ausufern wenn zwischen Controls inhaltliche Abhängigkeiten bestehen. Und dann hast du sehr viel Code.

Der Stichpunkt war auf den Update-Befehl selbst bezogen. Ich denke nicht, dass ich sowas gemacht hätte, denn es wird bestimmt in Unübersichtlichkeit ausufern - da geb ich dir Recht!