Erzeugung des Renderingcontext dauert Ewig..

[corpsman]

Guten Morgen Allerseits, mein Thema / Lösung könnte auch bei Multimedia rein, da der Fehler aber nur unter Windoof auftritt habe ich mir gedacht mache ichs mal hier rein.

Zum Thema :

Wenn ich eine von mir unter Linux entwickelte OpenGL Anwendung unter Windows Compilieren lasse, und diese dann ausführen möchte, dauert das erzeugen des Renderingcontextes ewig, und ich meine nicht 2-3 Sekunden sondern auch mal 30-100 ich hatte auch schon fälle da wurde es nie Fertig. Wer das gerne mal ausprobieren will, dem sei der Anhang empfohlen außer TOpenGLControl braucht das nur die normale LCL.

So nun habe ich also rausgefunden, dass wenn ich das Programm "verstecke" und wieder "zeige", dass dies das ganze beschleunigt.

Damit ist die Antwort auf mein Problem quasi durch einfügen folgender Zeilen am Ende des Procedure TForm1.OpenGLControl1MakeCurrent(Sender: TObject; Var Allow: boolean);
bereits gegeben.

Code: Alles auswählen

{$IFDEF WINDOWS}
  Form1.Invalidate;
{$ENDIF}

Nur verstehen tu ichs eigentlich nicht. Könnt ihr das Problem nachvollziehen ? Bzw. gibt es eine elegantere Lösung, denn durch meinen "Hack" wird die OpenGLControl1MakeCurrent nun 3 mal aufgerufen, bis dass die Anwendung "Nutzbar" wird. Unter Linux ists nur 2 mal. Gerade wenn man in OpenGLControl1MakeCurrent alle Spielegraphiken neu lädt, kann das schon unangenehm werden.

Gruß

Corpsman

[Bora4d]

Ich bin kein OpenGL-KOmponente Experte aber irgendwie zeichnest du falsch.
Das Programm tut nach Start nichts, wenn ich Formgröße ändere tauchen 2 Zeilen auf bei nochmal vergrößern 3.Zeile auf.
Ich glaube im Timer die Prozedur OpenGLControl1.DoOnPaint; tut nicht, nur deine Funktionen in OnResize zeichnen.

Getestet mit Xp-Sp3. Lazarus 0.9.31 (svn 34124), fpc 2.4.4

[Bora4d]

Falls du noch nicht gesehen hast im Lazarusordner gibts gute Beispiele:
\lazarus\components\opengl\example

[corpsman]

Meine Anwendung tut sehr wohl was,

diese Striche die du da siehst zegien dir an "Wann" und wie oft der Renderingcontext erstellt wird.

ab dem 2. Strich funktioniert auch die Schrift, solltest du die Kommentare im OnMakeCurrent wieder rein machen.

So wie du es beschreibst, scheint der Fehler bei dir auch zu sein, was meine Theorie und die notwendigkeit meiner Lösung zu bestätigen scheint ..

[marcov]

(Win7/32)

onresize tut nichts weil openglcontrol.align nicht alclient ist.

[corpsman]

*g*

das stimmt, nach erfolgreichern Initialisierung wird er Händisch 1 mal aufgerufen, will der User dann das Control in der Größe ändern, ist dieser code schon vorbereitet.

Was ihr hier seht ist mein Basis Sample, von welchem ich dann immer neue OpenGL Projekte ableite, aus diesem Grund sind hier ab und an nicht Aktive Quellcode teile drin.

Mir geht es nach wie vor nur darum, dass unter Windows ohne den "Fix" aus post 1 es eben sehr lange dauert, bzw. erst ein invisible / visible wechsel stattfinden muss. Bevor man den Renderingcontext effektiv nutzen kann..

[MAC]

Also bei mir geht es mit der OpenGL komponente recht flott, 1,2 sekunden und fertig ist das ding...
Zum rendern benutze ich

Code: Alles auswählen

OpenGLControll1.Invalidate //nicht Form1.Invalidate

Ich muss aber dazu sagen das ich das Thema nur gerade überflogen habe und nicht alles gelesen habe...

[corpsman]

Hallo Mac,

Dein "Überfliegen" war zu Grobmaschig, es geht nicht darum ein Repaint aus zu lösen. Sondern darum, dass (zumindest bei mir) die Routine "OpenGLControl1MakeCurrent" immer mindestens 2 mal aufgerufen werden muss, bevor ich eine OpenGL Anwendung nutzen kann. Das 1. Mal wird sie gleich nach on Create aufgerufen, da lade ich dan die OpenGL Dlls. Erst beim 2.mal kann ich via Texturen und anderen Späßen auf den OpenGL speicher zu greifen. Unter Linux wird das 2. Mal instantan ausgelöst und man merkt das eigentlich gar nicht ( wenn mans nicht speziel loggt ). Unter Windoof ist es so, dass das 2.mal nur aufgerufen wird wenn ich "Form1.Invalidate;" mache, oder eben das Fenster Verstecke und wieder sichtbar mache.

Es geht also nicht darum ein generelles Zeichnen aus zu lösen, sondern die korrekte Initialisierung des RC.

Ich habe ja auch schon eine Lösung eben das "Form1.Invalidate;" meine Frage ist hier eher, wie sich das erklärt, ob es ein Bug ist, der dann Reported gehört oder, und damit kann ich auch gut leben, ob das unter Windoof einfach so sein muss und eben so gemacht wird.

Gruß

Corpsman

[pluto]

Dein "Überfliegen" war zu Grobmaschig, es geht nicht darum ein Repaint aus zu lösen. Sondern darum, dass (zumindest bei mir) die Routine "OpenGLControl1MakeCurrent" immer mindestens 2 mal aufgerufen werden muss, bevor ich eine OpenGL Anwendung nutzen kann. Das 1. Mal wird sie gleich nach on Create aufgerufen, da lade ich dan die OpenGL Dlls. Erst beim 2.mal kann ich via Texturen und anderen Späßen auf den OpenGL speicher zu greifen.

Ich habe mir nur den Code angesehen. Mir fällt zum einen deine Aussage hier auf: " Das 1. Mal wird sie gleich nach on Create aufgerufen, da lade ich dan die OpenGL Dll..."
Im Code gibt es dazu ein Kommentar:

Man bedenke, jedesmal wenn der Renderingcontext neu erstellt wird, müssen sämtliche Graphiken neu Geladen werden.
Bei Nutzung der TOpenGLGraphikengine, bedeutet dies, das hier ein clear durchgeführt werden mus !!

Zum anderen: Warum nutzt du eigentlich ein Timer? OpenGL Anwendungen werden doch Klassischerweise im onIdl Event ausgeführt oder?
Ich hatte mich auch mal mit der DelphiGL OpenGL unit befasst. Ich hatte zwar Probleme, aber andere.

Ich denke, es könnte vielleicht auch darin liegen: Unter Linux erzeugt die dglOpenGL kein RC aber unter Windows schon. Nun hast du unter Windws Eventuell zwei RC'S so könnte sich das erklären lassen.

Aber wie deine Lösung da rein passt, kann ich mir nicht erklären. Wann genau machst du ein "Form1.Invalidate"? Invalidate löst eigentlich ein neu Zeichnen von From1 aus.... mehr nicht.Versuch mal Updatet und Repaint ob das auch geht...

[corpsman]

Lieber spät als nie *g* ich selbst habe keinen Windows rechner mehr, brauche also immer ein wenig zum testen ...

Zum anderen: Warum nutzt du eigentlich ein Timer?

Wenn du im OnIdle Renderst, und dein Graphikkartentreiber steht nicht auf V-Sync dann kann es je nach anwendung locker mehrere Hundert Frames per Second geben. Das belastet dein System nur unnötigerweise, da mehr wie in der Regel 60 FPS du sowieso nicht auf dem Monitor sehen kannst. Deswegen der Timer.

Das "Form1.Invalidate" rufe ich als letzte Zeile im OpenGLControl1MakeCurrent auf also bei z.B. meinem neuesten Project sieht das so aus :

Code: Alles auswählen

Procedure TForm1.OpenGLControl1MakeCurrent(Sender: TObject; Var Allow: boolean);
Begin
  If allowcnt > 2 Then Begin
    allow := false;
    exit;
  End;
  inc(allowcnt);
  // Sollen Dialoge beim Starten ausgeführt werden ist hier der Richtige Zeitpunkt
  If allowcnt = 1 Then Begin
    // Init dglOpenGL.pas , Teil 2
    ReadExtensions; // Anstatt der Extentions kann auch nur der Core geladen werden. ReadOpenGLCore;
    ReadImplementationProperties;
  End;
  If allowcnt = 2 Then Begin
    // glenable(GL_POINT_SMOOTH); das würde die Punkte Glätten führt aber nicht zu den Pixelfehlern, welche wohl nur auf nicht Nvidia Graphikkarten auftreten
    Create_ASCII_Font();
    // Der Anwendung erlauben zu Rendern.
    Initialized := True;
    OpenGLControl1Resize(Nil);
  End;
{$IFDEF WINDOWS}
  Form1.Invalidate;
{$ENDIF}
End;

Mit Form1.Updated; gehts nicht mit Form1.Repaint; initialisierts zwar den RC "schnell" aber meine OpenGL Ascii Font wird nicht initialisiert ( auch dann nicht wenn ich das if allowcnt = 2 auskommentiere.

[pluto]

Lieber spät als nie *g* ich selbst habe keinen Windows rechner mehr, brauche also immer ein wenig zum testen ...

Dann ist das Problem doch gelöst?

Wenn du im OnIdle Renderst, und dein Graphikkartentreiber steht nicht auf V-Sync dann kann es je nach anwendung locker mehrere Hundert Frames per Second geben. Das belastet dein System nur unnötigerweise, da mehr wie in der Regel 60 FPS du sowieso nicht auf dem Monitor sehen kannst. Deswegen der Timer.

Bei mal ein Sleep in das OnIDLE Event ein... das entlastet die CPU. Ein Sleep von 10 ms reicht schon aus...

Sehe ich das richtig, dass allowcnt dafür verantwortlich ist, dass das nur gemacht werden soll wenn "OpenGLControl1MakeCurrent" zwei oder drei Mal aufgerufen wurde(Je nachdem ob allwcnt auf 0 oder auf 1 steht)? Warum so? Wie oft wird OpenGLControl1MakeCurrent eigentlich aufgerufen?

[corpsman]

prinzipiell hättest du Recht, bei mir unter Linux gehts auch wunderbar. Ich veröffentliche aber sehr viel von dem was ich da so programmiere und will, das auch Win User in den genuß meiner Programme kommen.

was die OnIdle Geschichte angeht.

Sagen wir du hast einen Rendercode welcher 5ms braucht um alles zu berechnen und an die Graka zu senden. Dann willst du 60 fps = ca. 17ms per Frame, also baust du ein 11ms sleep ein. Alles schön und gut. Nun erweiterst du dein Programm um XY und dein Rendern braucht plötzlich 7ms. Bei deiner Variante Bricht die FPS automatisch auf ca 52 FPS ein, während in meiner Timer Variante die fpx bei ca. 60 bleibt.
man kann da nun Argumentieren, das man den Sleep wert anpassen kann, aber warum sollte ich mir diese Arbeit machen, wenn ich mit dem Timer das viel einfacher lösen kann.

Warum so? Wie oft wird OpenGLControl1MakeCurrent eigentlich aufgerufen?

Ich will das Laden aller Spiele Graphiken so selten wie möglich machen bei Balanced sind das mehrere MB, Da ich aus Erfahrung = viel ausprobieren weis, dass alles beim 1.mal erstellen des RC verworfen wird ( keine Ahnng warum ), überspringe ich dieses Laden. Alles nach dem 2. Mal macht in meinen Augen irgendwie auch keinen sinn, deswegen :

Code: Alles auswählen

Procedure TForm1.OpenGLControl1MakeCurrent(Sender: TObject; Var Allow: boolean);
Begin
  If allowcnt > 2 Then Begin
    allow := false;
    exit;
  End;

Viele Tests auf Linux und windows haben gezeigt, dass es so funktioniert. Warum es so funktioniert, weis ich nicht und mitunter deswegen habe ich den Thread aufgemacht..

[pluto]

Bei deiner Variante Bricht die FPS automatisch auf ca 52 FPS ein, während in meiner Timer Variante die fpx bei ca. 60 bleibt.
man kann da nun Argumentieren, das man den Sleep wert anpassen kann, aber warum sollte ich mir diese Arbeit machen, wenn ich mit dem Timer das viel einfacher lösen kann.

Ich muss gestehen, ich habe kaum Erfahrung mit OpenGL und alle Beispiele und Projekte die ich bisher gesehen habe, haben halt nicht im Timer gerendert... aber wenn es geht?
Warum nicht....

Aber nun zurück zu OpenGL...Ich denke hier werden wohl nicht so viele OpenGL verwenden oder vielleicht doch?
Es gibt noch ein gutes Forum für OpenGL
www.delphigl.com... wo du ja auch schon die Units von her hast(Teilweise), einige dort verwenden auch Lazarus und müssten dir eher weiter helfen können mit etwas Glück. Es gibt auch noch ein IRC Channel vom DelphiGL Forum...

Bitte nicht als Werbung verstehen, nur denke ich, passt das Forum einfach besser..... wenn ich mich Täusche bitte Sagen... dann behaupte ich das Gegenteil *G*
Man muss ja nicht alles als "Feind" betrachten oder?

[corpsman]

*g* Feinde sind wir hier nicht, ..

Auf den Regelmäßig stattfindenden Stuttgarter Lazarustreffen merke zumindest ich immer, dass sehr wohl ein Interesse an OpenGL herscht, es für viele aber eine doch sehr undurchsichtige Materie ist. Aus diesem Grund habe ich auf meiner Homepage auch extra eine Rubrik OpenGL eingerichtet. Das Forum auf delphigl.com kenne ich natürlich auch.

Wi ich einleitend auch schon schrieb, ist für mich das Problem ja bereits gelöst. Gepostet habe ich es hauptsächlich, damit andere Suchende eine Lösung finden. Wenn dann nebenher dabei raus gesprungen wäre, dass man mir erklären kann warum es funktioniert wäre das eine spitzen sache gewesen...

[pluto]

Deine Internet Seite gefällt mir recht gut, vielleicht wären kleine Bilder oder gar Bilder-Serien möglich/vorstellbar?