[linux-l] Open GL ohne Event Handling?

[Steffen Dettmer]

* Christoph Lange wrote on Tue, Oct 07, 2003 at 12:06 +0200:
> Kann mir jemand eine Bibliothek nennen, mit der ich OpneGL in ein
> Fenster ausgeben kann, ohne daß dies in einer Event Handling Loop
> geschieht?

Ich jedenfalls nicht. Aber ich glaub, das macht keinen Sinn,
oder?

> Hintergrund: Ich will INNERHALB eines Programmflusses einige wenige
> Zeichenanweisungen für OpenGL absetzen, so etwa:
> 
> öffne OpenGL-Window
> ...
> tue dies und jenes interessante,
> male jetzt ein grünes Rechteck in die rechte obere Ecke,
> tue jetzt wieder was anderes etc.
> ...
> schließe OpenGL-Window.

Malt denn niemand das Fenster? Wer kümmert sich um redraw, falls
es kurz von einem xterm verdeckt war? Reagiert jemand auf "exit"?

> Das Problem mit, z.B., glut ist, daß man eine OpenGL Event Loop
> startet, in der man lediglich innerhalb von Callbacks die Möglichkeit
> hat, etwas tun zu lassen. 

Na ja, eben wenn ein Ereignis nach Bearbeitung verlangt. Wenn nix
zu tun ist, macht man nichts (bei GUIs geht das einfache Modell
ja oft). Hast Du viel zu rechnen, was lange dauert?

> Dieses Callback aber, das für das Zeichnen der momentanen
> Darstellung der Szene verantwortlich ist, wird immer wieder neu
> aufgerufen, nämlich dann, wenn etwas neu zu zeichnen ist.

jo, dafür isser da :)

> UND, das ist mein Problem, wenn ich darin etwas anderes, einen
> kontinuierlichen Programmfluß, haben will, muß ich mein
> Programm fragmentieren und Zustände und Sprungmarken
> definieren, 

Korrekt. Meist sind events aber queue-bar. So kann ein Handler
ein Event queuen, in dem steht, was als nächstes gemacht werden
muß. Beispielsweise: "Viereck 17 fertig, Dreieck 19 berechnen"
oder sowas. Führt natürlich zu komplizierteren Designs,
vielleitch Producer/Consumer Pattern (was ich selbst nicht kenn
:)).

Ein kontinuierlicher Programmfluß kann ja auch nicht
"zwischendruch zeichen, auf exit reagieren und minieren"
ausführen oder sowas, was man aber von jeder GUI einfach
erwartet.

> Meine momentane Lösung ist das Kidnapping der Event Loop, indem
> ich innerhalb des Display-Callbacks einfach eine Endlosschleife
> mache.

Dann "hängt" Deine Bildschirmausgabe aber in dieser Zeit!

> Elegant ist das nicht. 

Sorry, würde das gar "falsch" nennen :)

> - gibt's da was anderes?!

Multithreading ist ja schon genannt worden - hat man ja auch
häufig im Zusammenhang mit "eventorientierter Programmierung, wo
dann doch mal was lange dauert". Der Thread sendet dann oft ein
"ich bin fertig" Event an die GUI (UpdateView-mäßig). Fand ich
bei JavaSwing ganz nett gemacht.

Da Du ja "Zeitgleich" Fenster malen, Maus verarbeiten und
"rechnen" mußt, ist ein single-threaded und kontinuierlicher
Programmfluß meiner Ansicht nach kaum möglich.

Vielleicht erzähle ich auch Mist, bin schon verdammt müde :)

oki,

Steffen

-- 
Dieses Schreiben wurde maschinell erstellt,
es trägt daher weder Unterschrift noch Siegel.