Hallo!

Ich habe folgendes Problem in meiner OpenGL-Anwendung und zwar nur mit ATI-Grafikkarten:
Die Anwendung läuft im Fullscreen (also BorderStyle:=bsNone und WindowState:=wsMaximized). Mit Rechtsklick soll sich ein ganz normales VCL-Kontextmenü öffnen (wie bei Windows eben üblich). Dieses wird aber nur selten angezeigt, ist aber bedienbar, d.h. wenn man ins Leere klickt, wird der Menüpunkt tatsächlich ausgewählt.

Nach viel, viel Haareraufen und Fehlersuche konnte ich den Fehler auf folgendes eingrenzen: Der Fehler tritt nur auf, wenn alles folgende erfüllt ist:
- ATI-Grafikkarte (in meinem Fall mit allen Treibern seit ich die Karte habe, also 2004 bis zum aktuellsten)
- BorderStyle:=bsNone
- WindowState:=wsMaximized
Nimmt man eines davon weg, setzt also z.B. den Border auf bsSingle oder den WindowState auf wsNormal, funktioniert alles wie es soll.

Da ich das kaum glauben konnte, habe ich es nochmal am OpenGL 1.5 mit VCL-Template von dieser Seite nachvollzogen - und tatsächlich, der gleiche Fehler tritt auf. Ich habe den Code mal als Attachment angehängt; wer es nachvollziehen will, kann bei TGLForm.FormCreate den BorderStyle bzw. WindowState ändern. Ansonsten habe ich in der Datei nur die Zeichenroutine von Idle nach OnPaint verschoben, was aber an dem Problem nichts ändert, sondern das Programm nur besser bedienbar macht in dem Fall mit dem Kontextmenü. Ach ja, und das Kontextmenü habe ich natürlich auch hinzugefügt.

Gibt es für das Problem vielleicht eine Lösung bzw. einen Workaround? Müsste ja eigentlich wirklich ein Bug in den ATI-Treibern sein - oder habe ich ein Brett vorm Hirn?

Viele Grüße,
Arno

"Leicht modizifiert"
Du musst über OnIdle Zeichnen. Dann funktioniert es.

Ist dir mal aufgefallen wie lahmarschig die ganzen Programme inklusive dem eigenen werden? Ich hab hier nen Petium 4 3Ghz HT und der braucht schatzungsweise knapp 600 Millisekunden um das Startmenü aufzumachen oder das ShowMessage('a'); auszuführen. Also das ist alles andere als Normal. Würde auch mal darauf tippen, das der Treiber das nicht so wirklich mag. Bzw habe mal die Erstellung des RCs auskommentiert, dann wars wieder wie normal. Was hasten du für ne Karte + Auflösung?

Hab hier ne X300SE @ 1280x1024x32Bit. Das ist Allerdings ne HyperMemory Karte. Also die Benutzt den Haupspeicher als Bildschirmspeicher.

Nein, tut es nicht (kannst es gerne ausprobieren). Das ändert gar nichts, abgesehen davon, dass das ganze System extrem langsam wird. Zum Neuzeichnen von veränderten Elementen ist OnPaint ja schließlich auch da. Windows zeichnet ja seine Buttons auch nicht ständig neu, sonst wäre deine CPU ständig unter Vollast. Ich sehe nicht ein, warum das plötzlich anders sein soll, nur weil jetzt über OpenGL gezeichnet wird. Wenn sich nichts ändert, muss auch nichts gezeichnet werden.

So, ich habe noch ein wenig weitergeforscht. Folgendes habe ich herausgefunden:
- Ein Panel auf die Form zu ziehen und darauf mit OpenGL zu malen, ändert an dem Problem leider nichts.
- Belässt man WindowState auf wsNormal und maximiert man das Fenster von Hand, also so...:
Width:=Screen.Width;
Height:=Screen.Height;
Left:=0;
Top:=0;
so tritt wieder genau das gleiche Problem auf. Macht man aber z.B. das Fenster 1 Pixel kleiner, geht alles, aber die Startleiste erscheint. Macht man es einen Pixel größer (also z.B. Screen.Width+1), ist die Startleiste weg und alles funktioniert einwandfrei.

Damit ist wohl ein (wie zu erwarten war) unschöner Workaround gefunden, der so aussieht:
- WindowState:=wsNormal;
- BorderStyle:=bsNone;
- Width:=Screen.Width+1; Height:=Screen.Height; Left:=0; Top:=0;
- glViewport wieder auf Screen.Width, Screen.Height stellen, damit der extra Pixel nicht angesprochen wird.

Fragt sich nur, ob solche Verrenkungen auf anderen Grafiktreibern oder mit späteren Treiberversionen auch noch funktionieren werden, oder ob dann z.B. die Startleiste wieder auftaucht. Die kann man zwar von Hand verstecken, aber das wäre dann doch ein sehr unschöner Hack.

Wenn jemand eine bessere Idee hat - immer her damit! Ich werde diese "Lösung" jetzt vermutlich mal als "ATI-Bug-Workaround" als Option in mein Programm einbauen...

Hi,

ich habe das selbe Problem mit Fullscreen.
Mir scheint es, als wenn das OpenGL Zeichnen nach dem Zeichnen des Menüs kommt und damit das Menü überpinselt. Bedienbar ist es dann ja noch.

Mein Prog läuft in normaler VCL in ClientRect der Form. Alles läuft ok und ich kann ein Pixelformat mit oder ohne Hardwarebeschleunigung auswählen. In beiden Fällen ist es ok (auf Nvidia und ATI Karten).

Wenn ich nun ein neues Fenster als Fullscreen erzeuge und in diesem das VCL Menü nutze (auf der Rechten Maus) funktiooniert es bei Nvidia auch voll ok (mit und ohne Hardwarebeschleunigung). Bei ATI jedoch habe ich genau dein angesprochenes Problem wenn ich ein Pixelformat mit Hardwarebeschleunigung nutze. Bei einem Pixelformat ohne Hardwarebeschleunigung ist auch dort alles ok und das Menü erscheint normal. Leider geht aber dann die Framerate in die Knie.

Leider habe ich auch allgemein ab und zu ein paar mysteriöse Effekte, wenn ich Hardwarebeschleunigung nutze. Manche Karten laufen Top, andere machen recht defizile und nicht zuodnungsfähige Fehler. Die konnte ich bei Nvidia (sogar bei Qudro FX 1400) und auch bei ATI beobachten.

Grüße
Ingo

@user69: Mir scheint es so, als bräuchten die Grafikkartenhersteller eine Weile, um zu begreifen, dass man mit 3D-Beschleunigung nicht nur Spiele machen kann... In den (halbwegs) aktuellen Treiberversionen scheint diese Erkenntnis aber wohl doch noch angekommen zu sein.
Was für mysteriöse Effekte beobachtest Du denn sonst noch so? Mir war bisher noch nichts aufgefallen, abgesehen von der Fullscreen-mit-ATI-Geschichte (und mein Programm ist nun schon seit gut 1,5 Jahren im Einsatz).

@Lossy eX: Sorry, mir war bisher noch gar nicht bewusst, dass du mich angesprochen hattest. Ich hatte dein Posting auf die Aussage von i0n0s bezogen... Das von Dir beschriebene Verhalten kann ich bei mir auch beobachten, auf einer ATI Radeon 9800 XL bei 1280x1024x32 Bit. Der Workaround löst aber auch dieses Problem.

Ich stelle in meinem Viewer CAD Daten dar (Kommerzielles Projekt) - www.3D-Tool.de
Dementsrechend versuche ich lieber etwas Performanceeinbußen hinzunehmen aber das Programm sicher laufen zu lassen (auf unterschiedlichster HW).
So benutze ich auch keine besonderen Extentions.

Wie gesagt ohne Hardwarebeschleunigung läuft es recht stabil und ich kann keine Probleme beobachten.
Hier ein paar beobachtete Effekte HW Beschleunigung:
-Selection dauert beim ersten Aufruf recht lange (auf einer SIS Notbook Grafikkarte auch jedes mal) von knapp ner sekunde bis hin zu dem Notebook mit 1-2 Sekunden bei gerade mal 50.000 Dreiecken. Das nervt mich am meisten.
- Vertexnormalen werden auf einer Quadro FX 1400 teilweise falsch dargestellt (es sieht einfach so aus als ob ein paar Vektoren verbogen sind).
- auf der ATI karte wird auch ein Panel nicht gezeichnet, das ich von der VCL in mein Fullscreenwindow genommen habe - Darstellung erfolg nur von den Eelemnten auf den Panel, wenn ich mit der Maus drüber streiche (wie mit einem Radiergummi)

...

Grüße
User69

Darf man fragen wieviel Leute an dem Projekt programmieren, und wie lange das schon existiert? Auch welche Sprache ihr benutzt würde mich interessieren. Sieht nämlich ziemlich doll aus, euer CAD programm.

_________________
Blog: kevin-fleischer.de und fbaingermany.com

Hallo,

3D-Tool (www.3D-Tool.de) existiert seit 1999 (zumindest liegen da die Anfänge und die Version 1, die aber kaum noch mit der heutigen Version etwas zu tun hat).

Im Prinzip bin ich der einzige der daran programmiert (naja zugegeben es ist schon mehr als nur ein Hobby geworden und frist mir manchmal schon zuviel Zeit). Ich habe da leider bisher niemanden in meiner Umgebung (nähe Mannheim) gefunden mit dem man in gewissen Themen zusammenarbeiten könnte und der auch dei entsprechenden Kenntnisse hat.
Einige 3D-Schnittstellen und die 2D-Schnittstellen habe ich aber zugekauft (die sind zu komplex als sie auch noch selbst zu entwickeln). Die Aufbereitung der Daten und der OpenGL Part sowie sämtliches Handling ist aber von mir.

Ansonsten entstehen einige Verbesserungen vor allem aus dem Einsaz (z.B. bei meiner normalen Arbeit im CAD Bereich) oder aus Kundenwünschen.

Viele Grüße

Respekt das du das Projekt solange am laufen hälst. Hast du das mal umgebaut, oder is da noch alter Code im Kern drinnen. Kann mir vorstellen, dass so alte Projekte irgendwan ne menge Codemüll mit sich rumschleppen, bzw. unübersichtlich werden.

Hast du das Projekt ausgibig geplant, oder nach gefühl geschrieben?
Und dann steht immer noch die Frage nach der Sprache im Raum.

_________________
Blog: kevin-fleischer.de und fbaingermany.com

Das ganze wurde in Delphi 4 geschrieben.

Umbauten gabs natürlich diverse, da ich keinen zukunftssicheren Entwicklungsplan habe.
Damit ergeben sich einfach Notwendigkeiten, die "Teilumbauten" oder Verbessereungen beinhalteten.
Ein generelles Neuschreiben des Codes gab es jedoch nie (dazu hätte ich auch nie Zeit gehabt).

Generell verzichte ich eher auf ein paar optische Spielereien oder auf den letzten Performancekik und halte damit das Aufwand-Nutzen Verhältnis gut.
Außerdem bin ich damit eher sicher, daß das Programm auch überall läuft.

Grüße...