Hallo Leute,
sorry für den unqualifizierten Threadnamen, mir fiel jetzt grad nix besseres ein.

Erläuterung:

Ich habe zu Testzwecken einen kleinen ImageViewer geschrieben. Dieser besitzt eine Liste in der verschiedene Bilder als simple Strings
stehen. Klicke ich nun eins davon an bzw. navigiere mit den Pfeiltasten durch die Liste, dann soll das Tool das jeweils selektierte Bild
im Viewport anzeigen. Dabei wird die Textur (GL_TEXTURE_2D) jedesmal neugeladen mit dem String aus der Liste.

Problem:

Dabei machen mir die ständigen Texturwechsel unheimlich Probleme. Wechselt man von einem Bild zum nächsten, dann kann es schon durchaus passieren, dass man 1-2 Sekunden nichts sieht und erst dann das aktuelle Bild angezeigt wird. Die Rede ist hierbei meist von Bildern mit mind. 1600 x 1200 Pixel Auflösung. Dargestellt werden sie indem ich auf 2 Quads per glTexCoord2f die Textureteile zeichne. Erwähne das nur um zu vermeiden, dass jemand annehmen könnte, es drehe sich hierbei um Performance Probleme. Nein, das nicht!
Problematisch sind nur die Übergänge durch die Schieberei der Textur an die GKarte.

Falls jemand jetzt gar nicht versteht, was ich meine, dann hier ein schematischer Ablaufplan:

Texturen via TOpenDialog laden -> Filestrings in TListView "gespeichert" -> Selektieren eines Bildes ---> Anzeige im Viewport

Und ---> ist hierbei das Problem. Hoffe ich konnte es erklären

Ich verwende glBitmap zum Laden der Texturen.

Meine Fragen nun dazu:
Ist das der richtige Weg um sehr große Bilder via OpenGL anzuzeigen?
Gibt es andere/bessere/schnelle Möglichkeiten hinsichtlich des Ladens der Texturen? (Kann ja schlecht alle Bilder gleich zu Beginn laden, es sind teilweise >500 Bilder )
Hat jemand vielleicht schon ein mal solch eine Thematik behandelt und kann mir da eventuell mit Erläuterungen aus seinem Programm helfen?

P.S. Bitte sagt nicht, dass diese Verzögerungszeit akzeptabel sei. Ich habe hier einen Core2Duo E8500 mit 2x 3,86 Ghz, 4GB RAM und einer 8800GT zur Verfügung. Und wenn der schon solche Zeiten aufweist, dann haben ältere Rechner ja noch mehr damit zu kämpfen. Das Tool soll ja gerade durch Schnelligkeit trumpfen.

Hoffe auf eure Tipps und Hilfe.
Grüße, Killian

_________________
Die Antwort ist 17, aber wie lautet die Frage?

Hi,

mir würden 3 dinge einfallen:

1) Benutzt du Mipmaps? Falls ja, mach das mal nicht.. die zu berechnen dauert zumindest via glu sehr lang.

2) versuch mal GL_TEXTURE_RECTANGLE_ARB statt GL_TEXTURE_2D, da könnte evtl auch einen guten geschwindigkeits schub bringen.

3) Sollten die bilder immer gleich groß sein kannst du mit glTexSubImage arbeiten statt die textur neu zu erstellen, das bringt einen riesen geschwindigkeits schub. Geht aber halt nur wenn es die gleiche größe hat.

Aya~

Hi Aya,

ich benutze keine Mipmaps, denke ich zumindest
Wie könnte ich denn sicher gehen, dass das auch defintiv nicht der Fall ist?

GL_TEXTURE_RECTANGLE_ARB bringt keinen Unterschied, habe es gerade getestet.

glTexSubImage hört sich gut an, ist aber leider in dem Fall nicht praktikabel, da die Bilder durchaus unterschiedliche Bemaßungen haben.



Gibt es denn überhaupt Viewer, die Bilder via OpenGL bzw. D3D anzeigen? Ich würde ja auch per Canvas zeichnen, aber ich brauch die Möglichkeit hinterher noch mit verschiedenen Werkzeugen das Bild zu manipulieren (Linien zeichnen zum Entfernungsmessen zweier Pixel etc.) und das geht einfach mit OpenGL wesentlich(!) performanter und schöner. Zumal mehrere Ebenen unterstützt werden soll, so dass ich Bilder im Viewport hin und her schieben kann.


Vielleicht noch andere Ideen, Anregungen, Hilfen??
Danke trotzdem!

Grüße, Killian

_________________
Die Antwort ist 17, aber wie lautet die Frage?

Bei der glBitmap gibt es eine Eigenschaft namens MipMap. Diese setzt du auf mmNone, dann werden keine mehr erzeugt. Aber die werden nach Möglichkeit soweiso auf der Grafikkarte berechnet.

Und sonst denke ich eher, dass das Hochladen nicht das Problem sein wird sondern das eigentliche Laden der Texturen. Wenn es sich dabei um JPEGs handelt, dann kostet alleine das Laden eines größen Bildes locker 800 ms. Mit der JPEG Implementation von Delphi bist du da ohne Probleme bei einer Sekunden oder darüber, da die auf "Qualität" aus ist.

Da könntest du evtl. mit einem "intelligenten" Modus bilder vorab laden. Das funktioniert aber nicht, wenn der Zugriff eher zufällig statt sequentiell ist. Einfach nen Thread anwerfen. Das nächste Bild laden und bei Bedarf zur Grafikkarte schicken oder verwerfen.

Ich würde dir empfehlen mit dem PerformanceCounter mal die einzelnen Schritte genau zu messen und zu testen wo die Zeit flöten geht. Also LoadFromFile. GenTexture. Und evtl. das Rendern. Nur wenn du weißt wo es hängt kannst du sinnvoll nach Alternativen suchen.

Du solltest auch überlegen ob das so geht wie du dir das denkst. Denn die Bilder die ich mit meiner Kamera machen kann sind locker über 2048x2048. Und das ist bei einigen Grafikkarten schon das Max der Texturgröße sein. Bzw bei vielen ist es 4096x4096 und mit dem Megapixelwahn bei Digicams dürften wir da schnell hinkommen.

Es sind alles ausnahmslos Bitmaps! Alle liegen im 24Bit BMP Format vor. Dekomprimierung etc. fällt also weg.
Sequentielle Abarbeitung ist auch nicht möglich, da ich nie weiß, welches Bild der User als nächstes in der Liste anklickt.

Um den sog. MPixelwahn mache ich mir keine Sorgen, die 2048 werden in keiner Dimension überschritten.

Mipmap in deiner Unit kann ich nicht ansprechen, da ich gar keine Instanz deiner Klasse habe, lediglich die Methode LoadTexture benutze ich und binde dann per glBindTexture.
Vielleicht ist das ja schon das Problem!?

Ich kann aber morgen abend mal ein paar PerfCounter Queries reinhängen, mal schauen, wo die Zeit davonfließt.

Was würdest du denn eher für einen ImageViewer empfehlen hinsichtlich der zunehmenden Bildgröße? Lieber auf OpenGL oder generell auf Hardware Unterstützung verzichten und lieber aufs Canvas zeichnen? Bestimmt nicht, oder?

Grüße, Killian

_________________
Die Antwort ist 17, aber wie lautet die Frage?

BMPs: Okay. Kompression fällt weg ja. Aber dafür muss wesentlich mehr von der Platte gelesen werden. Was auch nicht sonderlich schnell ist.


Wenn du mich fragst ja. Denn dadurch nimmst du dir die Möglichkeit auf die Textur und deren Einstellungen Einfluss zu nehmen.


Da muss ich passen. Kommt ganz darauf an was du GENAU damit vor hast. Allerdings ich persönlich bin von OpenGL überzeugt. Aber es kann in der ein oder anderen Situation auch Probleme mit sich bringen.

Wenn du schon soweit bist, dann würde ich bei OpenGL bleiben, also bilder bis 2048x2048 in den speicher zu schaufeln dauert aufjedenfall keine 1-2 sekunden.
Für die absolute kompatibilität bis auf die niedrigste opengl version, solltest du die texturen selber baken, also BMP laden, header auslesen, textur mit 2^n ausmaßen erstellen(newwidth>=currentwidth,newheight>=currentheight damit kein verlust entsteht) und die BMP rein kopieren.
Dabei musst du dann aber die texturkoordinaten für deine Darstellungsfläche anpassen(da man sonnst noch schwarze Flächen sieht und das Bild gestaucht wird).

edit:Ich empfehle folgende Lösung, alle Bilder in dds mit DXT5 convertieren und dann kannst die mit ~20 Zeilen Code auch lesen und direkt in den Speicher gepackt. 512x512 mit mipmaps dauert bei mir 9ms vom laden bis zum darstellen.

_________________
"Wer die Freiheit aufgibt um Sicherheit zu gewinnen, der wird am Ende beides verlieren"
Benjamin Franklin

Projekte: https://github.com/tak2004

Also die sollte mit NPOT keine Probleme machen. ATI macht da auch nur Probleme, wenn man MipMaps aktiviert hat. Das war jedenfals mal so. Zu mal sich das bei ATI besonders bei Zeichnen bemerkbar macht. Das Hochladen geht da sogar noch.

Nichts destro trotz stimmt die Aussage, dass POT kompatibler ist.