Renderkontext: Unterschied zwischen den Versionen
Flash (Diskussion | Beiträge) K (Formulierung - richtig?) |
BenBE (Diskussion | Beiträge) K (→Anlegen eines Renderkontext: Einige kleinere Korrekturen) |
||
| Zeile 6: | Zeile 6: | ||
{{Template:Hinweis|Dieser Abschnitt beschreibt das Vorgehen unter Windows. Unter Linux können Details abweichen (Wenn jemand mit Linux mehr Erfahrung hat, wäre eine Teilung und differenziertere Beschreibung erwünscht)}} | {{Template:Hinweis|Dieser Abschnitt beschreibt das Vorgehen unter Windows. Unter Linux können Details abweichen (Wenn jemand mit Linux mehr Erfahrung hat, wäre eine Teilung und differenziertere Beschreibung erwünscht)}} | ||
| − | Um überhaupt mit OpenGL arbeiten zu können, muss ein Renderkontext | + | Um überhaupt mit OpenGL arbeiten zu können, muss zuerst einmal ein Renderkontext angelegt werden. Dabei muss man einen vorhandenen [[Gerätekontext]] (DC) zugrunde legen. Ein Renderkontext spannt sich dabei immer über den gesamten Gerätekontext und damit über den gesamten Clientbereich des Fensters oder das gesamte Speicher-Bitmap, zu dem der Gerätekontext gehört. |
| − | Beim Anlegen werden sowohl auf der Grafikkarte als auch im RAM abhängig von den Einstellungen des Gerätekontextes ([[Pixelformat]], Höhe, Breite...) diverse Speicherbereiche reserviert, in | + | Beim Anlegen werden sowohl auf der Grafikkarte als auch im RAM abhängig von den Einstellungen des Gerätekontextes ([[Pixelformat]], Höhe, Breite...) diverse Speicherbereiche reserviert, in denen später dann [[Farbpuffer|Farb-]] oder [[Tiefenpuffer]], die Informationen der Statemachine, [[Textur]]en, [[Displayliste]]n oder [[VBO]]s abgelegt werden (natürlich werden auch einige Bereiche erst später dynamisch reserviert). |
=== Problem mit erweiterungsabhängigen Pixelformaten === | === Problem mit erweiterungsabhängigen Pixelformaten === | ||
| − | Ein bekanntes Problem bei der Tatsache, dass ein Renderkontext an einen Gerätekontext gebunden ist und dass man das Pixelformat eines Gerätekontextes nur ein einziges Mal festlegen kann, ist, dass man für einige Einstellungen im Pixelformat erst wissen muss, ob die passenden Erweiterungen zur | + | Ein bekanntes Problem bei der Tatsache, dass ein Renderkontext an einen Gerätekontext gebunden ist und dass man das Pixelformat eines Gerätekontextes nur ein einziges Mal festlegen kann, ist, dass man für einige Einstellungen im Pixelformat erst wissen muss, ob die passenden Erweiterungen zur Verfügung stehen. Um das zu ermitteln muss man allerdings wiederum einen Renderkontext erstellt haben. |
Um dieses Problem zu umgehen, wird häufig ein Testgerätekontext auf einem versteckten Fenster erstellt, auf dem dann ein Testrenderkontext erstellt wird, wo man die Erweiterungen abfragt. | Um dieses Problem zu umgehen, wird häufig ein Testgerätekontext auf einem versteckten Fenster erstellt, auf dem dann ein Testrenderkontext erstellt wird, wo man die Erweiterungen abfragt. | ||
Version vom 5. August 2008, 10:40 Uhr
(Mehr Informationen/weitere Artikel) Hier fehlen noch einige Angaben zur Erzeugung und Verwendung. Zudem sollte noch mal jemand drüberschauen, ob die angegebenen Informationen zu den enthaltenen Info's korrekt sind. |
 |
Der Renderkontext enthält alle nötigen Informationen, die eine Zeichenfläche und die zu dieser zugeordneten Ressourcen beschreiben. Diese Informationen enthalten dabei Angaben zum verwendeten Pixelformat, den Abmessungen der Zeichenfläche (Höhe, Breite, Aspekt-Ratio), sowie Angaben zur Lage der Datenpuffer für Farb-, Stencil-, Tiefen- und Transparenz-Informationen. Zudem enthält der Render-Kontext allgemeine Statusinformationen wie die Art und Dicke zu zeichnender Linien, die zum Zeichnen zu verwendenden Texturen sowie andere Angaben, die für das Zeichnen notwendig sind.
Inhaltsverzeichnis
Anlegen eines Renderkontext
|
Dieser Abschnitt beschreibt das Vorgehen unter Windows. Unter Linux können Details abweichen (Wenn jemand mit Linux mehr Erfahrung hat, wäre eine Teilung und differenziertere Beschreibung erwünscht) |
Um überhaupt mit OpenGL arbeiten zu können, muss zuerst einmal ein Renderkontext angelegt werden. Dabei muss man einen vorhandenen Gerätekontext (DC) zugrunde legen. Ein Renderkontext spannt sich dabei immer über den gesamten Gerätekontext und damit über den gesamten Clientbereich des Fensters oder das gesamte Speicher-Bitmap, zu dem der Gerätekontext gehört.
Beim Anlegen werden sowohl auf der Grafikkarte als auch im RAM abhängig von den Einstellungen des Gerätekontextes (Pixelformat, Höhe, Breite...) diverse Speicherbereiche reserviert, in denen später dann Farb- oder Tiefenpuffer, die Informationen der Statemachine, Texturen, Displaylisten oder VBOs abgelegt werden (natürlich werden auch einige Bereiche erst später dynamisch reserviert).
Problem mit erweiterungsabhängigen Pixelformaten
Ein bekanntes Problem bei der Tatsache, dass ein Renderkontext an einen Gerätekontext gebunden ist und dass man das Pixelformat eines Gerätekontextes nur ein einziges Mal festlegen kann, ist, dass man für einige Einstellungen im Pixelformat erst wissen muss, ob die passenden Erweiterungen zur Verfügung stehen. Um das zu ermitteln muss man allerdings wiederum einen Renderkontext erstellt haben.
Um dieses Problem zu umgehen, wird häufig ein Testgerätekontext auf einem versteckten Fenster erstellt, auf dem dann ein Testrenderkontext erstellt wird, wo man die Erweiterungen abfragt.
Diese Problematik tritt häufig bei Multisampling (Antialiasing) auf, da dies eine entsprechende Erweiterung beziehungsweise die Fähigkeit der Hardware benötigt und im Pixelformat festgelegt sein muss.
Einflussnahme auf den Renderkontext
Bei jedem Aufruf einer Funktion von OpenGL, die an der Art und Weise, wie etwas gezeichnet werden soll, oder die selbst etwas zeichnet, nimmt OpenGL Veränderungen an den im Renderkontext hinterlegten Angaben vor. Diese Veränderungen spiegeln dabei die auszuführende Operation (z.B. Ändern der Linienstärke beim Zeichnen mit GL_LINES) in Form einer Status-Änderung wieder (Ändern des Wertes, der die zu verwendende Linien-Breite angibt).
Renderkontextübergreifende Daten
OpenGL bietet (zumindest unter Windows) mittels wglShareLists die Möglichkeit, kontextspezifische Objekte wie Texturen oder Displaylisten übergreifend über zwei Renderkontexte zu verwenden. Dies ist zum Beispiel im Falle einer Editoranwendung hilfreich, die mehrere Viewports hat, die aus technischen Gründen nicht in einem Renderkontext liegen können. Für jeden Viewport alle Texturen und VBOs beziehungsweise Displaylisten zu laden, wäre natürlich viel zu großer Aufwand. Statt dessen benutzt man etwas wie wglShareLists, um die Objekte nur einmal laden zu müssen.
Das Thread-Problem
Ein Problem, auf das man im Zusammenhang mit dem Laden von Daten in den Renderkontext später eventuell treffen kann ist, dass man einen Renderkontext nur so lange verändern kann, wie man sich in demjenigen Thread befindet, in dem der Kontext erstellt wurde. Das heißt, dass man Texturen oder andere OpenGL-Objekte nicht aus einem nebenläufigen Lade-Thread heraus erstellen kann. Wohl aber kann man die Daten erstmal in den RAM laden und dann an den Hauptthread weiterreichen, der sie dann an die Grafikkarte schickt.
