4. Erstellung eines Worker-Threads zur Grafikausgabe

Erstellung eines Worker-Threads zur Grafikausgabe

  • S

    @DocShoe sagte in Erstellung eines Worker-Threads zur Grafikausgabe:

    Edit:
    Sind sämtliche Messdaten zum Zeitpunkt des Zeichnens bekannt? Oder werden die nach und nach ergänzt? Worauf ich hinaus will: Wird DrawLines nur ein Mal aufgerufen oder immer wieder, wenn neue Messdaten eintreffen?

    Ich glaube, die Frage ist untergekommen, wäre aber interessant zu wissen.

    Eventuell lassen sich auch Berechnungen in einen Thread auslagern, so dass der Hauptthread dann nur grade neu berechnete Endwerte anzeigen muss. Aber auch hier ist eine entsprechende Synchronisation nötig.

    Aber wo genau der Flaschenhals ist, ist mit den Informationen schwer zu erraten.

    Ich würde das mit der Bitmap versuchen. Du kannst ja messen, wie lange das dauert. Und dann hast du das Teilproblem zumindest schon so weit separiert, dass man da vlt einfacher andere Performance Optimierungen vornehmen kann.

    0
  • ?

    @elmut19 sagte in Erstellung eines Worker-Threads zur Grafikausgabe:

    Ich sehe dann auch, dass der Bildschirm neu aufgebaut wird und die Grafik wieder von vorne gezeichnet wird.

    Und warum startet es wieder von vorne?
    Wie kann das überhaupt sein, wenn der GUI Thread doch blockiert ist?

    0
    E
     1 Antwort
  • Y

    @elmut19 Von Threads würde ich erst einmal Abstand nehmen. Sie alleine sind nicht die Lösung für das ursprüngliche Problem.
    Mit Double-Buffering, also das Zeichnen in eine Bitmap, würden sich sehr viele, wenn nicht alle Probleme auf einen Schlag lösen lassen.
    Der Grundgedanke dahinter ist eigentlich nur, dass Zeichenoperationen nur dann und direkt erfolgen, wenn sie nötig sind und beim Zeichnen in den DC lediglich die Bitmap in den DC geblittet wird.
    Wenn du das allerdings das erste Mal machen möchtest, würde ich dringend ein Testprojekt dafür empfehlen...
    Es wäre dann auch einfacher, bei konkreten Problemen zu helfen.

    0
  • E

    @manni66
    Leider weiss ich den Grund für den Wiederaufbauf der Grafik nicht.
    Ich denke, dass das Betriebssystem zu lange keine Antwort bekommt.
    Auch habe ich keinen eigenen GrafikThread. Es ist das Hauptprogramm, das da zeichnet.
    Ich habe auch schon probiert durch abfragen der Message Queue das zu beheben. Hat nix gebracht,

    0
    ?
     2 Antworten

  • @elmut19
    Kommt drauf an, wo deine Zeichenoperation angeschubst wird. Es gibt mehrere Gründe, warum dein Fenster ein WM_PAINT bekommt. Und wieso kann man das nicht rausfinden? Einen Brechpunkt auf DrawLines setzen und sich den Callstack angucken.

    0
    E
     1 Antwort
  • ?

    @elmut19 sagte in Erstellung eines Worker-Threads zur Grafikausgabe:

    Auch habe ich keinen eigenen GrafikThread. Es ist das Hauptprogramm, das da zeichnet.

    Das ist klar. Wenn aber

    DrwaLines();	// Dauert sehr lange

    nicht bendet wird, kann es nicht neu starten.

    @elmut19 sagte in Erstellung eines Worker-Threads zur Grafikausgabe:

    Leider weiss ich den Grund für den Wiederaufbauf der Grafik nicht.

    Dann finde es heraus. Ein Thread ist nicht zum totschlagen von Problemen, die man nicht versteht, geeignet.

    0
  • E

    @DocShoe
    Ich war bisher leider zu blöd dazu, den Grund für das WM_PAINT rauszubekommen.
    Und leider weiss ich es immernoch nicht (ausser Timeout). Und auch nicht, wie ich es verhindern kann.

    Dann dachte ich (sogar schon seit Längerem), ein Thread wäre ein Experiment wert.

    0
  • Y

    Ich finde das eigentlich nachvollziehbar: Während des extrem langen Zeichenvorgangs werden keine Nachrichten abgeholt, Windows stellt Inaktivität fest und graut das Fenster aus. Nach Abschluss der Zeichenoperation und dem Leeren der Queue veranlasst Windows das Programm, das Fenster neu zu zeichnen und das Spiel beginnt von vorne.

    0
    E
     2 Antworten

  • @yahendrik

    Das denke ich auch. Vielleicht gibt´s irgendwo noch nen Timer, der ein Neuzeichnen auslöst. Oder es treffen schneller neue Messdaten ein als der Graph gezeichnet werden kann. Aber jetzt wird´s spekulativ.

    0
    E
     1 Antwort
  • E

    @yahendrik
    Das ist eben derzeit auch meine Überlegung.
    Und bei teilweise ein paar Millionen Daten, die auch mehrenen Messgrafen zugeordnet werden müssen, ist es nicht unbedingt ein sehr schlechter Quellcode. Es dauert einfach.
    Ich habe schon länger nach Optimierungen gesucht.

    0
    Y
     2 Antworten

  • @elmut19

    Dann erzähl doch mal ein bisschen. Wie sieht die Darstellung aus? Wie werden die Linien gezeichnet? Bietet sich da ggf. eine Datenreduktion an? Ich kann mir nicht vorstellen, wie man so viele Datenpunkte sinnvoll anzeigen kann, wenn man wirklich alle Datenpunkte anzeigt.

    0
  • E

    @DocShoe Ich selbst (oder mein Vorgänger) haben keinen eigenen Timer gesetzt.
    Daher denke ich ans Betriebssystem.
    Aber auch hier hat die Standard-Routine

    	while (::PeekMessage(&struMessage, NULL, 0, 0, PM_NOREMOVE)) {
		if (::GetMessage(&struMessage, NULL, 0, 0)) {
			::TranslateMessage(&struMessage);
			::DispatchMessage(&struMessage);
		}
		else {
			break;
		}
	}

    leider auch nix gebracht.

    0 1 Antwort

  • @elmut19
    Natürlich nicht, was soll denn das passieren? Das PeekMessage drumrum braucht man nicht, die übliche Message Pump sieht so aus:

    MSG msg;
BOOL success;

while( (success = GetMessage( &msg, NULL, 0, 0 )) != 0 )
{ 
   if( success== -1 )
   {
      // handle the error and possibly exit
   }
   else
   {
      TranslateMessage( &msg ); 
      DispatchMessage( &msg ); 
   }
}
    0
    E
     1 Antwort
  • E

    @DocShoe
    Die Methode werd ich dann auch nochmal probieren.
    Aber was heisst "braucht man nicht"?

    So wie Du das ausdrückst, würde es bedeuten, dass es auch seine gewünschte Wirkung verfehlt!

    0 1 Antwort

  • @elmut19

    Was ist denn die Wirkung?

    Edit:
    Käse

    0
    E
     1 Antwort
  • E

    @DocShoe
    Bei mir hats eben gar nix gebracht. Auch keinen Lock.
    ... Also meine Version.

    0 1 Antwort

  • @elmut19

    Ne, ich hab´s auch falsch verstanden. Aber so, wie du die Pump implementierst, kann sie eigentlich nicht funktionieren. Sobald ein Mal alle Nachrichten abgearbeitet sind liefert PeekMessage 0 zurück und verlässt die while Schleife. Damit ist für deine Anwendung dann Feierabend. Oder gibt´s noch mehr Stellen, wo Nachrichten behandelt werden?

    0
    E
     1 Antwort
  • E

    @DocShoe
    Es werden natürlich diverse Buttons abgearbeitet.
    Somit gibt es schon solche Abfragen, auch irgendwo explizit.
    Dort funktionieren sie auch. Auch mit PeekMessage().

    0 1 Antwort

  • @elmut19
    Passiert das an verschiedenen Stellen? Also wird mal hier die MQ behandelt, dann mal da und später noch woanders?
    Eigentlich egal, das hat mit dem ursprünglichen Problem jedenfalls nichts zu tun. Also zurück zum Thema:
    Wo genau entsteht denn der Engpass? Hast du einen Profiler, den du benutzen kannst? Oder ist DrawLines als Flaschenhals identifiziert?

    0
    E
     1 Antwort
  • E

    @DocShoe Mit dem Profilerim Visual Studio kenne ich michnicht so gut aus.
    Aber der Flaschenhals liegt schon eindeutig in dieser DrawLines().
    Ich kann das sogar genauer sagen.
    Innerhalb werden unterschiedliche Bereiche der GRafikausgabe angesprochen. Zudem wird für jeden Punkt der Grafik (oder auch "LineTo()") ein neuer "Pen" angesprochen, da es fas beliebig viele Grafen innerhalb der Grafikausgabe gibt.
    Dann werden auch alle Werte vorab gelesen, um die Zeitachse zu bestimmen. Das aber geht relativ schnell.
    Also es gibt sicher ein paar Optimierungsmöglichkeiten.
    Aber ich habe noch nicht so viel Optimierungen gefunden,
    und ich denke, dass es nicht genug bringen wird.
    Und ich gebe auch zu, dass ich da auch noch was machen muss.

    Ich dachte mir, dass es einen Versuch wert wäre, einfach mal einen Thread einzusetzen und damit zu experimentieren.

    Wenn alleine die Grafik zuende gezeichnet würde, wäre das ein grosser Erfolg.

    0 1 Antwort
Anmelden zum Antworten