@Coder007
hatte ich auch so verstanden und macht mir dadurch leider auch weiter Hoffnung auf einen anderen besseren Weg.
Mehr als mein jetziges Vorgehen zu beschreiben, den Code zu posten und um Stellungnahme zu bitten

Aber eigentlich geht es auch nur darum, ob diese beiden Anzeigen im Code so richtig implementiert sind. Wenn mir jemand dazu etwas sagen könnte, wäre mir sehr geholfen. kann ich aber nicht. Weshalb ich jetzt aufgegeben hatte auf weitere Hilfe zu hoffen.

Meine Aussage:

C/C++ mit/ohne Linux mit/ohne Echzeitkernel scheidet von meiner Seite für diese Anwendung leider aus. ging eher in Richtung T-Virus, der darauf zweimal hinwieß.

Ich hatte halt noch gehofft, dass jemand der das TestProgramm runtergeladen hat auf Anhieb einen krassen Fehler gesehen hat, aber egal.
Also schonmal vielen Dank an alle die hier schon geduldig Zeit investiert haben oder vielleicht doch noch investieren.
Als derzeitiges Fazit scheint ja der Weg mit den zwei Timern und zwei ConcurrentStack (oder ähnlichem mit manuellen Locking) hier der beste zu sein, wenn man mit c#/.net/WPF/WES7 arbeiten muß. Wie auch hier schon frühzeitig vorgeschlagen. C/C++ mit/ohne Linux mit/ohne Echzeitkernel scheidet von meiner Seite für diese Anwendung leider aus.
Bewußt ignoriert habe ich bestimmt nichts und wenn das so rüber gekommen ist entschuldige ich mich natürlich dafür.

Gruß luciluke

Hallo,
will nicht vielleicht doch jemand noch Kritik am Code oder an der vorgehensweise zur Anzeige machen? Ich habe meinen Weg ja jetzt grob beschrieben und die Testapplikation wurde ja schon verschiedentlich herruntergeladen. Es geht nicht um "(=>100% identische Frameraten)" wie behauptet wird, sondern um möglichst performanten Code vom Zeitpunkt des Datenerhalts bis zur Anzeige.
Wenn meine Vorgehensweise so schon in Ordnung ist, wäre das zum einem gut zu erfahren, aber Verbesserungsvorschläge würde ich auch gerne ausprobieren.

Hallo Coder007,
das ist ein Problem der Simulation, da das Zeit-Daten Packet ( hier SmpteFrame ) in dem TestTimer Tick Event erzeugt/ hochgezählt wird und dieser dann ja als erstes zusammenbricht (kürzester Intervall), d.h. die "Zeit" der SmpteFrame wird nicht mehr alle ungefähr 30-40ms erhöht. Im realen Fall kommt das Zeit-Daten Objekt über Netztwerk rein und hat dann natürlich auch die "aktuelle Zeit" bzw. die Zeit die angezeigt werden soll.
Also so krasse Sachen passieren nicht, das ist eine Einstellungssache der Simulation. Wenn ich bei mir WorkOn mit SomeWork count = 20000 habe und die Pegelanzeige ein bzw. aus schalte, dann sehe ich eine etwas schleppendere Anzeige und auf dem J1900 kommt es teilweise zum Stocken.
Auch die Zeiten für die anderen Timer sind ja kürzer als nötig, um überhaupt jetzt mal zum Verständniss einen Unterschied beim umschalten zu sehen. Die zusätzliche Arbeit, die entsteht wenn die Pegel angezeigt werden sind der Punkt. Ob diese zusätzliche Arbeit, durch das Binding im Hintergrund oder weiß nicht genau was da noch passiert, oder aber durch Zusammenspiel DirectX, GPU ... weiß ich nicht.
Die Frage ist, ob das was ich von Packetempfang bis zu den Anzeigen mache so richtig bzw. am besten sogar "optimal" für die Performance ist.
Kannst Du diesen Weg den nachvollziehen, oder soll ich nochmal besser beschreiben?

ps.: rechts unterhalb von der TimeCode Anzeige wird übrigends die verstrichene Zeit je Zeitanzeige Event angezeigt. Also, wenn der Zeitanzeige Timer auf 60 steht, dann sieht man da z.B. dann im guten Fall sowas zwischen 50 und 80. Dient nur dem Verständniss.

Ich versuchs mal...
In TcpServer der _testTimer stellt die Simulation der eingehenden Packete dar, d.h. die Methode Receive ist noch fake.
_model.TcpServer_DataReceived(buffer); ist dann die erste richtige Methode, danach wird dieser buffer wieder als Antwort zurückgeschickt(fehlt jetzt hier).
In TcpServer_DataReceived(byte[] buffer) werden die Daten verarbeitet.
ProzessKbData(kbData_2);//=====> simmuliert hier zusammen mit dem kleinen Tasten Fenster die Keyboardbefehle die eigentlich in den empfangenen Daten enthalten sind.
In _at.ProzessData(atData) findet die eigentliche Arbeit statt.
_model.TimeCodeBufferString.Push(_model.RefreshTimeCodeString(RefInOutFrameCopyTcOnly)); stellt den Timecode String in den ConcurrentStack<string[]> TimeCodeBufferString.
In ProzessSmpteFrameAsync(incommingSMPTE); werden die Daten bearbeitet und nach der Bearbeitung wird in Push_FaderData() eine List<BargraphData> erstellt, die im Prinzip einfach nur die 129 Bargraph Werte enthält. BargraphData implementiert INotifyPropertyChanged.
Diese Liste wird in einen zweiten ConcurrentStack<List<BargraphData>> BargraphBuffer gestellt.
Das war es mit der Bearbeitung und die bearbeiteten Daten werden zurückgeschickt.
Jetzt gibt es noch einen Timer _ltcGuiTimer der alle x ms den letzten wert aus dem ConcurrentStack<string[]> TimeCodeBufferString holt, die weiteren Werte, falls vorhanden, verwirft und dann in RefreshTimeCodeWPF(string[]) in einem Objekt StatusBoxData : DependencyObject ein DependencyProperty ändert. An dieses DependencyProperty ist in MainWindow.xaml entsprechend ein Textblock gebunden.
Und es gibt einen Timer _faderGuiTimer der alle x ms den letzten Wert aus dem ConcurrentStack<List<BargraphData>> BargraphBuffer holt, die weiteren Werte falls vorhanden verwirft und dann in RefreshBargraphGui(List<BargraphData> faderData) eine zweite List<BargraphData> DicCurBargraphData aktuallisiert. An die BargraphData Objekte in dieser Liste sind "BargraphUserControls " in BargraphViewModel.cs gebunden. Und diese Liste von BargraphUserControls dienen als ItemsSource für eine angepasste ListBox zur Anzeige der Pegel. Leider benutze ich mal die Bezeichnung Bargraph mal Fader.
Wenn nötig beschreibe ich das auch gerne nochmal genauer.

Die zwei Fenster sind Absicht, das sind dann zwei Monitore im Vollbildmodus und auf einem kann dann noch manchmal was anderes angezeigt werden, aber das fehlt jetzt hier. Wie im Eingangsbeitrag beschrieben läuft auch sonst nichts anderes auf dem Rechner, es gibt auch keine Maus und kein Keyboard. Relevant ist das, da es vom rendern her doppelte Belastung bedeutet.
Das ist eine Time Code Anzeige und die läuft bei SMPTE30 mit 30 (Film Bildern) Frames pro Sekunde, daher die 30.
Also ich habe einen Intel Core i5-3570 (wohl eher mittel schnell und auch nicht die neuste Grafikkarte) und wenn ich bei WorkOn die Pegelanzeige ein bzw. aus schalte, dann sehe ich eine schleppendere Anzeige. Bei einem Atom mit integrierter Grafik stolpert dann alles.

@Coder007
danke, dass Du dir das mal anschaust.
Oben rechts läuft ja die Zeitanzeige, um die geht es. Wenn man in der Methode "SomeWork()" den count entsprechend einstellst, dass eine gefühlte Verlangsamung, bzw. ein anderes Muster an der letzten Stelle dieser Zeitanzeige zu erkennen ist, wenn man zwischen Pegel on/off umschaltet, dann hat man das was ich meine. Die Zeiten für die Zeit und die Pegel Anzeige können auch größer gewählt werden, aber ich denke bei der Zeitanzeige sollte es nicht mehr als 90 und bei der Pegelanzeige nicht mehr als 120 sein ( ich schreibe besser mal nicht ms ). Habe es hier jetzt nur mal relativ kurz eingestellt, um überhaupt einen Unterschied erkennen zu können, da ich nicht glaube, dass hier jemand vor ein Rechner mit Celereon oder Atom Prozessor sitzt.
Gut zu sehen ist auch, dass links oben bei der FPS Anzeige (nur für Testzwecke) der Count ziemlich unbeirrt durchläuft. Das die Zahl an den letzten zwei Stellen keinen informativen Wert haben ist klar, aber trotzdem erkennt man wohl am Muster eine vermeintliche Gleichmäßigkeit. Und um diese geht es.
Aber eigentlich geht es auch nur darum, ob diese beiden Anzeigen im Code so richtig implementiert sind. Wenn mir jemand dazu etwas sagen könnte, wäre mir sehr geholfen. Ist z.B. das erste mal, dass ich etwas mit WPF und MVVW gemacht habe.

Hallo,
da unter anderem Palin, erfreulicher Weise, noch nicht ganz aufgegeben hat, habe ich jetzt das Projekt mal auf das nötigste zusammen geschrumpft und die eingehenden Daten über einen Timer simmuliert. Die Refreshzeiten für den "Zeit anzeigen Timer (60ms)" und den "Bargraph anzeigen Timer (90ms)" können einfach ein/umgestellt werden. So wie das Program jetzt eingestellt ist läuft es auf meinem Entwicklungsrechner gleichmäßig, egal ob die Pegel unter Last angezeigt werden oder nicht, auf dem Rechner mit dem J1900 Processor jedoch nicht, oder nicht ausreichend. Es wird also ganz gut das Orginal simmuliert.
Ist jetzt nicht sonderlich kommentiert und sortiert, da ich annehme, daß man sowieso kein ganzes Projekt anhängen kann/soll, aber wie soll ich sonst die Zusammenhänge erklären. Sehr viele Codeausschnitte sind wohl auch nicht übersichtlicher, oder? (<- ernstgemeinte Frage, dann mache ich das)

ps.:
Um das doch nochmal kurz klar zustellen. Ich weiß genau, daß sowohl Windows 7 als auch WES7 keine Echtzeit Systeme sind, und ich verstehe nicht wieso mir hier teilweise das Gegenteil unterstellt wird.
Aber wenn das Program auf dem einem Windows 7 Rechner gleichmäßig genug läuft und auf dem anderen nicht, dann darf ich ja wohl behaupten, daß es nicht "nur" !!! an Windows liegt.
Das es auch an Windows und .net mit GC usw. liegt ist schon klar. Trotzdem würde ich halt gerne das beste rausholen. Es kann ja gut sein, daß ich irgendwo einen krassen Fehler mache.

Zitat aus Anfangsbeitrag:

Mit beschäftigt und ausprobiert habe ich unter anderem Windows Forms, WPF, WPF mit Windows Forms Host, RenderTargetBitmap, SharpDX/SlimDX mit/ohne WPF Host, usw. .

WPF Drawing Performance
bestätigt auch meine Tests, auf sehr unterschiedlicher Hardware (s.a.: RenderCapability.Tier, RenderOptions.ProcessRenderMode usw.) Weswegen ich auch unter anderem Windows Forms verworfen habe, da XP (XPe) keine Option mehr ist.

Gameloop scheidet wohl aus, da die Datenverarbeitung (Antwort erstellen/zurückschicken) höchste Priorität hatt. Hatte ich mich im Rahmen von DirectX usw. auch mit beschäftigt.

Hallo Abt,
ist mir jetzt nicht so ganz klar, warum Du verärgert bist, bzw. Du mir jetzt hier unterstellst Sachverhalte nicht zu verstehen, zu denen ich mich gar nicht geäußert habe.

Das Auge kann informativ nicht mehr als 3-4 verschiedene Werte pro Sekunde kurzfristig verwerten. Erkennen kann es mehr, aber nicht sachlich verarbeiten.

Wo bitte habe ich irgendwo etwas gegenteiliges behauptet. Ich rede immer von erkennbar fehlender Gleichmäßigkeit.

Wenn Du mit zwei Timern zwei Label aktuallisieren läßt und ein Timer läuft mit 60ms und einer mit 90ms, beide greifen auf die gleiche Zahl zu, die mit einem Timer alle 30ms von 1 bis 30 hochgezählt wird, dann siehst Du da einen Unterschied. Und wenn Du nun eine Anzeige hast und diese zwischen diesen beiden Geschwindigkeiten springt bzw. schwankt, dann sieht das extrem schlecht aus und ist bei dieser speziellen Anwendung nicht akzeptabel. Und wenn es mit einem leistungsfähigerem Prozessor geht, dann liegt es halt eben nicht nur an Windows oder .Net, sondern kann auch am Code liegen. Und ob ein Gerät, lüfterlos gebaut werden kann oder nicht ist auch schon ein signifikanter Unterschied. Und wenn sich heraustellen sollte, dass es nicht geht bzw. ich es nicht hinkriege, dann muß halt ein leistungsfähigerer Prozessor her.

Aber Du hast selber geschrieben:

Die höchste Gleichmäßigkeit, die er erreichen kann (denke ich), ist alle ~50-100ms die Anzeige aus einem Datenpool durch einen Timer zu aktualisieren.

Ja, das wäre doch perfekt, da würde ich halt gerne landen und deshalb habe ich hier um Hilfe gebeten.
Ich habe nur in der Problemstellung die 33ms erwähnt, sonst rede ich immer nur von Gleichmäßigkeit.

luciluke hat leider bis jetzt überhaupt nicht verstanden, oder ignoriert es, dass exakt alle 33ms etwas zu verarbeiten und dann auch noch zu zeichnen in dieser Umgebung nicht möglich ist.

wo bitte habe ich zu dieser Schlußfolgerung Anlass gegeben.

Meine Aussage.

Ja, es soll einfach nur gleichmäßig laufen und ich mache das auch im Moment schon mit zwei Timern alle 90ms die Zeitanzeige und alle 150ms die Pegelanzeige.
Aber auch das schwankt.

Was ich nicht verstehe ist das Fazit, aber nun genug zu meiner Ehrenrettung.

Hallo Abt, Hallo Palin
ich kann das jetzt nicht so stehen lassen, das ich das nicht verstanden hätte.

In meinem letzten Post habe ich lediglich die Frage von pinki beantwortet und die Pakete kommen nunmal alle 33ms +-3ms rein. Und ich habe die Problemstellung von "nicht häufig genug" auf "nicht gleichmäßig genug " richtiggestellt, da Palin danach fragte.
In meinem vorletztem Post habe ich doch auch geschrieben:

Ich versuche jetzt nochmal die Variante mit zwei Timern und zwei ConcurrentStack für jeweils Zeit- und Pegel-Anzeige, da ich ja eigentlich auch davon überzeugt bin, daß dies die beste Lösung ist.

und da bin ich dabei, ist halt etwas umfangreicher.
Und wenn ich da ein einigermaßen befriedigendes Ergebniss hinbekomme, versuche ich mal in Auszügen den gesamten Weg zu posten, um schauen zu können, wo es noch besser geht. Allein für die Anzeige der Zeit in WPF gibt es ja schon einige unterschiedlich Wege.

Der tote Gaul ist also fleissig und bestimmt nicht beratungsresistent.
Im Gegenteil ich freue mich ja, das Ihr mir helft. Und das habt Ihr jetzt schon!