folgendes:
In einem fertigen Programm wird ein Fenster verwendet, dass aus einer DLL heraus erstellt wird. Dazu werden einer exportierten Funktion der DLL die Angaben über Fenstergröße, -position, Parentwindow (natürlich das, in dem das Fenster dargestellt werden soll) und andere, anwendungsspezifische Infos wie Hintergrundfarbe o.ä. mitgeteilt. Diese Funktion registriert dann eine neue WindowClass und erstellt mit dieser ein neues Fenster. Das Fenster hat seine eigene WndProc, in der Dinge wie Klicks aufs Fenster und ähnliches verarbeitet werden. Zusätzlich kann man über weitere exportierte Funktionen auf diverse Eigenschaften Einfluss nehmen, so z.B. die Hintergrundfarbe ändern.

Funktioniert alles wunderbar. Wie erwartet läuft das ganze auch im Hauptthread des aufrufenden Programms.

Nun möchte ich zwei Sachen ändern: Zum einen soll die WndProc des Fensters in einen eigenen Thread ausgelagert werden, damit die doch recht aufwendigen Zeichenoperationen nicht die Benutzung des Hauptprogramms stören.

Zum anderen sollen verschiedene Instanzen dieses Fensters erzeugt werden können, die völlig unabhängig voneinander in eigenen Threads laufen.

Zunächst hatte ich mir nun gedacht, eine Klasse WindowManager zu schreiben, die innerhalb der DLL instanziiert wird. Diese Klasse verwaltet nun Objekte der Klasse Window, d.h. legt sie an, verwaltet Zeiger darauf in einem vector, gibt Zugriffsmöglichkeiten und gibt die Windows bei Bedarf wieder frei. Den generellen Zugriff wollte ich weiterhin über statische Funktionen der DLL ermöglichen. Dazu sollte bei Erzeugung eines neuen Windows eine eindeutige Nummer vergeben werden, die dem Hauptprogramm mitgeteilt wird und beim Aufruf der DLL-Funktionen verwendet wird, um das Fenster korrekt zu identifizieren.

Jedes Mal, wenn nun ein Fenster erzeugt wird, soll der dazugehörige Thread starten. Prinzipiell soll die Anzahl der maximal erzeugbaren Fenster nur von der Leistung des Rechners oder des Betriebssystems begrenzt werden (Gibts eigentlich eine maximale Anzahl Threads pro Prozess in WinXP/2000?).

Nun ist meine Frage, ob diese Ansatz erfolgversprechend oder von vornherein zum Scheitern verurteilt ist? Meine Erfahrungen mit Windows-Threads sind bisher äußerst oberflächlich, daher bin ich mir möglicher Fallstricke nicht wirklich bewusst.

Wichtig ist vielleicht noch, dass in den Fenstern mit OpenGL gezeichnet wird. In meiner bisherigen Variante funktioniert dies gut, bei den Threads bin ich mir da nicht sicher. Immerhin weiß ich schon, dass ich den Rendering Context für jeden Thread neu anfordern und wieder freigeben muss.

Wenn jemand einen hilfreichen Kommentar dazu hätte, würde ich mich über eine Antwort freuen!

Gruß
Martin

Nun möchte ich zwei Sachen ändern: Zum einen soll die WndProc des Fensters in einen eigenen Thread ausgelagert werden, damit die doch recht aufwendigen Zeichenoperationen nicht die Benutzung des Hauptprogramms stören.

Das ist unmöglich. Ein Fenster und alle läuft immer in dem Thread, in dem es erzeugt wurde. Auch dort kommt die Fensternachricht an.

mad_martin schrieb:

Zum anderen sollen verschiedene Instanzen dieses Fensters erzeugt werden können, die völlig unabhängig voneinander in eigenen Threads laufen.

Antwort siehe oben.
Ich kann nur dringend abraten solche threadübergreifenden Fenster zu erzeugen, die dann auch noch Ihre Parents in anderen Threads haben. Das kostet mehr Performance als es überhaupt bringt.
Jede Nachricht, die an einen anderen Thread laufen muss löst eine Threadsynchronisation aus.

mad_martin schrieb:

Nun ist meine Frage, ob diese Ansatz erfolgversprechend oder von vornherein zum Scheitern verurteilt ist? Meine Erfahrungen mit Windows-Threads sind bisher äußerst oberflächlich, daher bin ich mir möglicher Fallstricke nicht wirklich bewusst.

Es geht nicht! Fenster sind threadafin. Wohersoll hier ein Performance Vorteil kommen, wenn sowieso der User die Darstellung verzögert sieht.

Was wäre im Falle z.B. eines Fehlers in meiner WndProc, der verhindert, dass die Nachricht korrekt abgearbeitet wird (z.B. Endlosschleife,...)? Würde das das komplette Programm runterziehen, da die WndProc ja nicht mehr verlassen wird?

gruß
Martin

Würde das das komplette Programm runterziehen, da die WndProc ja nicht mehr verlassen wird?

es würde zumindest dazu führen, dass das fenster auf nix mehr reagiert...

Also wäre es tatsächlich sinnvoller, die Fenster im Thread des Hauptprogramms erzeugen zu lassen? Ist der Overhead bei Nachrichten zwischen Threads tatsächlich so groß? Ist es generell nachteilig, Fenster auf Threads zu verteilen oder nur in meinem Fall?

Alle Fenster einer UI Einheit sollten in einem Thread liegen.

Der Overhead ist:
Wird eine simple Nachricht an den anderen Thread gesendet via SendMessage, dann kehrt SendMessage nicht zurück bis dieNachricht bearbeitet wurde.
D.h. aber in diesem Fall. Die Nachricht wird nicht direkt an die WNDProc gegeben, sondern in die Nachrichtenschleife eingereiht und erst wenn GetMessage, das nächste mal ausgeführet wird und diese Nachricht an die Reihekommt wird sie berabeitet und dann kann der aufrufende Thread weiterarbeiten.

Das ist eine Threadsynchronisation und genau in diesem Fall reihen sich ale Aktivitäten der Fensterlinear hinereineinader und man nichts von den Thraeds.

Dazu kommt, dass man ultraleicht Deadlocks bauen kann...

mad_martin schrieb:

Was wäre im Falle z.B. eines Fehlers in meiner WndProc, der verhindert, dass die Nachricht korrekt abgearbeitet wird (z.B. Endlosschleife,...)? Würde das das komplette Programm runterziehen, da die WndProc ja nicht mehr verlassen wird?

Logo! Was denkst denn Du? Das ganze ist doch nur ein Thread und wenn Dein Code läuft, dann läuftnichts für ein anderes Fenster in dem Thread!

gruß
Martin

Wahrscheinlich ist es am sinnvollsten, nur die Zeichenroutine in den Thread auszulagern, den man dann einfach mal schlafenlegen kann, wenn gerade keine Aktualisierung benötigt wird. Die Bearbeitung der Benutzereingaben ist im Gegensatz zur Darstellung zu vernachlässigen und kann dementsprechend ohne Probleme im normalen Hauptthread vonstatten gehen.

Das Problem war halt nur, dass ich mir über die von dir erwähnte Threadsynchronisation so nicht klar war und gerne die Fenster schön voneinander getrennt laufen lassen wollte. Aber jetzt weiß ich wieder mehr und werde einen etwas anderen Ansatz verfolgen.

gruß
Martin