Erstellung eines Worker-Threads zur Grafikausgabe

DocShoe

@elmut19
Problem:
Meine Grafikausgabe ist zu langsam, und wenn ich das in einen Thread verpacke stürzt mein Programm ab.

Antwort:
Du brauchst nen nebenläufigen Thread, der mit seinen eigenen GDI Objekten arbeitet und musst das mit dem Hauptthread synchronisieren

Reaktion:
Das ist mir zu kompliziert.

Reaktion, Teil 2:
WTF? Wasch mich, aber mach mich nicht nass?

elmut19

@DocShoe
Na ja, möglichst einfach eben.
Wenn ich das brauche, muss es eben sein.
Ich habe das zumindest noch nicht gemacht.

Mein Programm stürzt auch nicht ab, da ich mit dem Thread noch gar nicht so weit bin.
Ich muss den erst mal bauen.
Und das scheitert schon an der Deklaration.

Zur Bitmap:
ich kann den Bildschirm nicht ein oder zwei Minuten leer lassen, bis die Bitmap gezeichnet ist.
Wenn, dann ist es mir schon viel lieber, man sieht, wie die Grafik aufgebaut wird.
Dann weiss man auch, dass etwas gemacht wird.

Und wie geht das?
Wie deklariere ich alles?

DocShoe

@elmut19
Das ist eher viel zu erklären, und ich kenne mich mit der MFC nicht mehr aus. Du kannst aber die WINAPI benutzen und dir die Funktionen CreateCompatibleDC , CreateCompatibleBitmap, BitBlt, CreateCriticalSection, EnterCriticalSection , LeaveCriticalSection und WaitForSingleObject angucken. Und natürlich SelectObject, DeleteObject und CloseHandle. Und vermutlich noch ein paar andere.

Edit:
Hier ist in der Paint Methode schon mal erklärt, wie man eine Offscreen DeviceContext und -Bitmap erstellt.

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

Na ja, möglichst einfach eben.

steht im Widerspruch zu

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

Wenn, dann ist es mir schon viel lieber, man sieht, wie die Grafik aufgebaut wird.
Dann weiss man auch, dass etwas gemacht wird.

elmut19

@manni66
Nun ja, die Anforderung wäre dann eben "ohne Bitmap" und dann eben auch alles, was man dazu braucht.

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

Da mein Programm auf diese Art die Grafik nicht fertigzeichnet und stattdessen
mit dem Zeichnen ständig von Neuem beginnt ("Programm antwortet nicht"),

"Programm antwortet nicht" heisst nicht, dass "ständig von Neuem begonnen" wird. Du solltest erst mal herausfinden, was eigentlich passiert und warum es so langsam ist.

elmut19

@manni66
Ich sehe ja, dass im Fenster-Kopf der Anwendung diese Meldung steht "Programm antwortet nicht".
Ich sehe dann auch, dass der Bildschirm neu aufgebaut wird und die Grafik wieder von vorne gezeichnet wird.
Ich habe mir den Quellcode auch schon sehr oft angesehen..
Leider habe ich noch keine Möglichkeit gefunden, den schnelle zu machen.

Schlangenmensch

@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.

@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?

yahendrik

@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.

elmut19

@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,

DocShoe

@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.

@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.

elmut19

@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.

yahendrik

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.

DocShoe

@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.

elmut19

@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.

DocShoe

@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.

elmut19

@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.

DocShoe

@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 ); 
   }
}