Um mal wieder was von mir hören zu lassen :

Ich habe jetzt ein Programm geschrieben, dass in einem Fenster zwei Bereiche anzeigt. In beiden werden die gleichen Texturen benutzt, jedoch in anderer Anordnung. In beiden Bereichen kann man außerdem die Ansicht getrennt voneinander verschieben. Bislang habe ich das Problem so gelöst, dass ich mir über einen Zwischenschritt die Koordinaten umgerechnet habe (und somit auch die Translation "von Hand" berechnet habe - ist "nur" 2D) und beides in einen Kontext gezeichnet habe. Das funktioniert so auch hervorragend und bereitet keinerlei Probleme.

Da ich das Projekt aber ganz gerne noch ein bisschen erweitern würde (noch mehr Bereiche ), wird die Umrechnerei langsam doch etwas kompliziert. Außerdem bin ich auch davon ausgegangen, dass es erhebliche Geschwindigkeitsvorteile mit sich bringt, diese Rechnerei hardwaregesteuert vornehmen zu lassen. Deshalb habe ich versucht, zwei verschiedene Kontexte für die Bereiche zu erzeugen. Dabei bin ich hier im Forum aber auch auf Artikel gestoßen, in denen davon abgeraten wird, weil das zu Geschwindigkeitsnachteilen führt (häufiger Kontextwechsel). Was könnt ihr mir denn jetzt empfehlen?

Außerdem hab ich natürlich auch wieder ein Problem mit Texturen . (Ich benutze die glBitmap.) Wie gesagt geht es darum, in beiden Kontexten die gleichen Texturen zu benutzen. Dummerweise werden sie jedoch nur in demjenigen Kontext angezeigt, der aktiviert war, als zum ersten Mal GenTexture für die jeweilige Textur aufgerufen wurde. Muss man jetzt für jeden Kontext eigene Texturenobjekte anlegen? Und wenn ja, woran liegt das? Man müsste doch zumindest einen übergeordneten Wert im Speicher halten können, der dann abwechselnd verschiedenen Werten zugewiesen wird.

Vielen Dank für eure Antworten,
Ogridi

Um deine Objekte (Texturen, DLs) zwischen den Kontexten zu sharen gibt es die Methode wglShareLists. Mit der Methoden teilen sich die Kontexte alle erstellten Objekte. Durch häufigeres aufrufen kannst du auch mehr als 2 Kontexte miteinander sharen. Du solltest dann aber dafür sorgen, dass alle Objekte und Listen in einem Kontext erstellt werden. Weiß nicht ob es probleme gibt, wenn du das mal so und mal so machst. Außerdem werden wohl deine bereits erstellten objekte weggeschmissen, wenn du einem Kontext anweist er solle sich die Listen aus Kontext XYZ holen. Also gleich nach dem erstellen sharen.

Ja. Häufiges Wechseln kann zu Geschwindigkeits einbußen führen. Aber da vertreten ich die Meinung, dass es ganz darauf ankommt was du damit vor hast. Wenn es wirklich um jedes bisschen Geschwindigkeit geht solltest du dir was anderes überlegen. Wenn es keinen unterschied macht ob es nun 134 oder 135 fps sind dann ist es wurscht. Aber auch da sollte man bedenken, dass in den meisten Fällen immer noch der Programmierer selber der größte Flaschenhals ist. Bedeutet fehlerhafte Konzepte, ungünstige Strukturen oder einfach nur nicht genutztes in der Hardware. Oder Falschbenutzung. Das wird in jedem Fall mehr zeit in Anspruch nehmen.

Sonst hättest du aber nur die Möglichkeit alles in einem Kontext zu rendern. Also einen großes Fenster bei welchem du jedesmal den Viewport einstellst und dann nur die einzelnen Teile renderst. Wobei das unter Umständen auch langsamer sein kann. Gehen wir mal davon aus, das du 4 Teile hast. Sobald ein Teil neu gezeichnet werden muss (Repaint vom Form) musst du alle 4 Teile neu zeichnen. Wenn du 4 einzelne Kontexte hättest bräuchtest du nur einen neu zeichnen. In diesem Falle wären getrennte Kontexte sogar schneller. Die Betrachtungsweise im Wiki und in Tuts geht meistens immer von Spielen aus. Wenn du aber anderes schreiben willst dann liegen die Prios auch anders.

Das mit den Koordinaten neu berechnen habe ich nicht gerallt. Da denke ich aber einfach, dass du ein Problem in deiner Struktur hast. Kann ich aber nicht beurteilen, da ich die nicht kenne. Oder du hast einfach einen Denkfehler.

Thx. Zunächst einmal gute Nachrichten, dass ich das Konzept nicht verwerfen muss .



Ich hatte eigentlich auch vor, mit verschiedenen Tabs zu arbeiten. Dann muss ich aber wohl beim Laden der Texturen sämtliche Renderkontexte aus allen Tabs sharen (auch die, die eventuell nie gebraucht werden)? Wenn ich im Verlauf der Anwendung neue Texturen zu den alten hinzufüge und dann nochmal alles share, sollte das aber keine Probleme machen, oder?





stark vereinfacht dargestellt. In Wirklichkeit ist das alles über drei Parameter verschoben und einen gestaucht, glaub ich ^^. Aber immerhin bin ich beruhigt, dass verschiedene Kontexte durchaus sinnvoll sein können. Hätte mich nur geärgert, wenn ich mir die Mühe mache, das alles mit "GL-Methoden" zu reorganisieren und am Ende erklärt mich jeder GL-Programmierer für verrückt, warum ich das geändert habe ^^.

Wie gesagt kommt es immer darauf an was du damit vor hast. Wenn die Kontexte fenstertechnisch getrennt sind hast du keine andere Wahl. Und nicht immer ist die geschwindigkeit so extrem wichtig. Die Probleme sind in spielen aber normal auch ganz andere. Wenn du den anderen Kontext mit ActivateRenderingContext aktivierst dann übergib bitte ein False als letzten Parameter. Also der erste Aufruf mit True dann werden die Extension geladen und sonst false. Da die Extension sich in der Regel nicht verändern und das Laden richtig an Performance zieht.

Noch mal zum Sharen. Du weißt damit dem Kontext an er solle sich alle seine Objekte aus dem Kontext XYZ holen. Da wird nicht nur die aktuelle Liste übertragen sondern die greifen beide auf die selbe Liste zu. Also ein aufruf und sie sind auf Ewig verbunden. Das soll auch bedeuten, dass die Objekte nicht kopiert werden sondern lediglich mehrfach benutzt werden. Also ist es egal ob 2 oder 20 Kontexte shares. Falls das deine Frage war.

Ich muss ehrlich gestehen, dass ich es noch nicht ausprobiert habe wie es aussieht wenn du Kontext A und B shares und dann jeweils in A und B Objekte erstellst. Weiß nicht ob OpenGL das so ohne weiteres schluckt aber eigentlich (so richtig drüber nachgedacht) sollte er es schon ohne Probleme verkraften. Macht ja sonst eigentlich keinen Sinn. Solltest dann aber diese so früh wie möglich sharen nicht damit dann schon jeweils objekte existieren. Könnte mir vorstellen, dass er die dann einfach wegwirft.

Danke! Das sollte mir reichen .

Man muß für zwei Fenster nicht zwei RCs erstellen sondern kann den einen Rendercontext mit wglMakeCurrent auch nachträglich noch an andere Fenster binden solange das Pixelformat exakt das gleiche ist.

Bleibt nach dem Verschieben das auf dem ersten Fenster 'gemalte' erhalten?
..und geht das auch bei zwei Panels auf einem Fenster?
Würd mich echt interessieren, weil damit ja auch ein nicht unergeblicher Speicheraufwand wegfällt(z.B.: nur ein Tiefenpuffer statt vier)

_________________
Manchmal sehen Dinge, die wie Dinge aussehen wollen, mehr wie Dinge aus, als Dinge.
<Esmerelda Wetterwax>
Es kann vorkommen, dass die Nachkommen trotz Abkommen mit ihrem Einkommen nicht auskommen und umkommen.

Sorry, ich hab doch noch ein Problem:

Ich kann zwar jetzt zwei Kontexte verbinden, wenn ich aber einen dritten hinzunehme, sind nur noch die letzten beiden verbunden. Hier also RCMini und OrgRC, RCMain und OrgRC nicht. Wenn ich die letzte Zeile weglasse oder die Reihenfolge vertausche, funktionierts (aber dann ist halt RCMini und OrgRC nicht verbunden). Auch wenn ich in der zweiten Zeile als zweiten Parameter RCMain angebe, funktionierts nicht.



Ich habe den Code direkt unter die Erstellung der Kontexte gesetzt. Davor wird nur DC und RC dreimal zugewiesen; sie werden nicht initialisiert und es werden keine Texturen zugewiesen.

Irgendwelche Ideen

Also der erste Parameter ist der HauptRC. Der zweite Parameter ist jeweils der RC dem du die Listen zur Verfügung stellen möchtest. So hatte es bei mir mit 3 RCs geklappt. Das ist alles ein bisschen verwirrend beschrieben. Selbst in dem MSDNs begreife ich es auf anhieb nicht.

Danke, das wars. Die Parameterreihenfolge hat nicht gestimmt.

Und wieder einmal thx =).