Tach,

ich habe nen problem, ich lade in ner OpenGL app in einem 40ms High res timer
eine Texture im JPEG Format. Ganz normal als Datei.

Das ist ziemlich langsam, dauert locker über 150 ms an ner 2,8 GHz maschine.

Es muss alle 40ms ablaufen und das laden und ins opengl bringen darf nicht länger als 15-20 ms dauern.

Was wäre da der sinnvollste weg das zu lösen ?

Habe natürlich einige versuche schon gemacht, und geprüft wie lange das laden dauert.
Nen JPEG mit 720x576x24bpp in 40 KB brauch locker 300 ms bis es als Texture in OpenGL geladen ist.

Wäre es schneller wenn die Bilder in einem TFileStream sind und man nur noch hin und her seeked um das jeweilige bild zu holen ?

Ein Problemm bei JPG ist das die Daten erst noch entpackt werden müssen. Wenn es wirklich nicht anders geht, dann würde ich diesen Vorgang von einem parallel laufenden Thread machen lassen.

Ich weiß nicht was du mit dem TFileStream erreichen willst. Entweder du hast die Bilder von schon vorher zu Verfügung und lädst sie gleich in den Texturspeicher deiner Grafikkarte, oder du must sie sowieso noch vorer von der Datei in diesem Stream laden. Hmm Momment mal, mit Streams habe ich noch nicht so viel gearbeitet, kann es sein das dieser TFileStream nur eine Möglichkeit darstellt eine Datei auszulesen?

MfG
Flo

_________________
Danke an alle, die mir (und anderen) geholfen haben.
So weit... ...so gut

Hmm...wenn schon dann TMemoryStream.
Darf ich fragen, warum musst du so "intensiv" bilder laden?
Und eine Vermutung von mir : Wäre es nicht schneller *.bmp oder *.tga (uncompressed) zu laden, da muss man kein dekomprimierungs Algo beim Laden benutzen.

_________________
"Meine Mutter sagt : 'Dumm ist der, der Dummes tut'." - Forrest Gump

Also ich denke mal du hast 2 Flaschenhälse. Einmal das JPEG Format. Das zu dekomprimieren dauert etwas. Ähnlich sieht es mit png aus. Also würde ich spontan zu einem unverschlüsseltem Format tendieren. Was natürlich deine Daten um ein vielfaches aufblasen würde bei 40 KB für ein Bild in PAL Auflösung. Und dann bei einem etwas langsameren Datenträger oder so wäre das auch nicht viel schneller. Du kannst ja mal schauen ob es etwas bringen würde, wenn du an dem JPEG ein paar Einstellungen vornimmst. (vor dem Laden des Bildes ist klar) Performance und Smoothing

Evtl würde sich dabei aber auch direkt ein AVI anbieten. Sulaco hat da ein Sample in dem ein Video dargestellt wird.

Zusätzlich dazu würde ich das Uploaden optimieren. In eine bestehende Textur mit glTexImage ein Bild zu kopieren dauert am längsten. Es ist schneller die Textur zu löschen und komplett neu anzulegen oder die Daten glSubTexImage hoch zu laden.

Evtl gibt es noch irgendwelche neuen Technologien dafür. Die sind mir aber so jetzt nicht bekannt. Aber in jedem Fall solltest du wohl von jpeg eher Abstand nehmen.

Also über die TFileStream bzw. TMemoryStream methode kriegs ich geschafft nen Jpeg zu laden und anzuzeigen in 22ms.
Allerdings nicht in OpenGL. Hab nur das Bitmap in nen TImage packen lassen.

Mit OGL dauerts länger als 400 ms

Die AVI methode hab ich auch schon ausprobiert, das kann man total knicken da hier VFW verwendet wird mit einem Lossless Codec. Sobald ich der AVI nen xvid oder sonsst was verpasse, bekomm ich kein einziges PFrame mehr

Es ist das folgende problem bei uns: Wir haben 115.000 Bilder im JPEG Format.
Unser 40 ms Timer errechnet über nen algo ne Bildnummer, und dann muss das jeweilige bild in weniger als 40ms geladen und auf den schirm gebracht werden.

Ob es jetzt nen Bild oder nen Videofile ist egal, wichtig ist nur die tatsache es muss schnell passieren da noch erheblich viel anderer rotz nebenbei läuft.

Und natürlich muss jedes Bild Compressed sein, jpeg eignet sich von der compression hervorrangend. 40 KB anstatt 1,4 MB ist schon nen unterschied.

Ich probier da schon seit gut 3-4 monaten rum und hab mir schon tonnenweise sachen angeguckt, aber irgendwie wills nicht so gehen wies soll

Also bei Länger als 400ms ist irgendetwas im argen. Normal sollte das nicht so lange dauern. Ich meine wenn ein Bild auch einen Alphakanal hat geht es auch noch mal schneller. Logischerweise darfst du dann unter keinen Umständen die Glut zum hochladen verwenden. Ich hatte das auch schon ausprobiert (mit 512x512) und dabei hatte ich jeweils noch eine Funktion auf das Bild angewendet. Und das lag bei ca 50 ms. Inklusive Funktion die in etwa die Hälfte der Zeit beachsprucht haben müsste.

Aber mal ne andere Frage. Ist die Reihenfolge der Bilder willkürlich oder vorrausberechenbar. Weil wenn sie Vorrausberechenbar ist, dann würde ich die Last auf verschieden Rechner verteilen. Also eine Client/Server Architektur. Sprich du hast 2-3 Rechner die die Bilder von einer Freigabe laden in eine Queue schreiben und dann zum Server schicken auf das er immer 4-5 Bilder im Speicher hat. Die Clients dürfen dann auch mal 10 oder mehr Bilder im Speicher haben. Du kannst dann immer Aktuell auf ein Bild zugreifen wären im Hintergrund wieder neue übertragen werden. Ist zwar reichlich aufwand und geht logischerweise auch nur im Lan mit mindestens 2-3 Rechnern. Dein Renderrechner hat dann nur die Last mit dem Hochladen und das kannst du noch optimieren.

Wobei ich keine Ahnung habe wozu du das überhaupt genau brauchst. Das wäre in so einem Fall wirklich hilfreich. Vor allem was du damit bezweckst und was was für hardwaretechnische Möglichkeiten du zur Verfügung hast. Und was du dafür an Zeit zur Verfügung hast. Also ist es privat oder beruflich.

Und ich würde ein mal Systematisch durchprobieren wie lange das Hochladen mit welchen Format braucht. Immer mit ein und dem selben Bild. Und dann nicht nur ein Bilder sondern so viele wie möglich in 1 Minute oder so. Um sinnvolle Ergebnisse bekommen zu können. Einfach um mal zu sehen was für Vorraussetzungen du brauchst und so etwas machen zu können. Und um zu sehen wo die Hardware den Geist aufgibt. Schau dir auch mal das Pixel Buffer Object an. Vielleicht hilft dir das ja auch schon.

Ich hab mir mal n Prog geschrieben, dass Bildschirmfotos schießt, und die auf die Platte legt, um später nen Film (AVI oder so drauß zu machen). Is ganz praktisch, wenn man irgendwas am Desktop "filmen" will. Wie auch immer, ich hab festgestellt, dass es schneller geht, die Bilder in JPGs umzuwandeln und auf die Platte zu legen, als sie unkompremiert zu speichern. Die Festplatte scheint wohl um einiges langsamer zu sein, als der JPG-Codec. Vielleicht gilt das auch fürs lesen.

Wie hast du das Laden denn eigentlich programmiert? Kannst du den Ausschnitt vielleicht posten?

Von LAN würde ich übrigends abraten. TCP ist zu langsam, UDP unsicher, dann musst du darauf dein eigenes sicheres Protokoll aufbauen, ...

_________________
[18:30] tomok: so wie ich das sehe : alles. was nich was anderes ist als nen Essay ist nen Essay

hi, i'm a signature viruz, plz set me as your signature and help me spread

@Al: Du kannst die auch direkt als AVI Speichern, ohne sie vorher zu sammeln. Mach ich auf Arbeit auch so. Such dazu mal im Forum. Findest bestimmt was.

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

Je nachdem wie es ausgelegt ist hast du damit auch durchaus recht. Wenn du die Bilder auf einem Client vorlädst und zum Server schickst, der die dann noch für 200 ms in eine Queue legen kann, dann spielt die Geschwindigkeit vom Lan kaum eine Rolle. Denn das rausziehen aus der Queue dauert keine 2ms. Wenn du es aber Zeitkritisch gestalten möchtest. Also jetzt Bild anfordern und dann drauf warten: Dabei ist LAN natürlich nur noch ein zusätzliche Bremse aber alles andere läuft nebenher und Bremst den Renderrechner kaum aus.

Lädts du immer das selbe Bild ? dann kannst es doch einmal laden, dekomprimieren und dann benutzen, anstatt jedesmal auf die datei zuzugreifen

Also ich hab schon ein fehler gemacht:

Hab jedes mal glTexImage2D gemacht, anstatt glTexSubImage2D.
Bau auch grad das mit dem AVI laden via VFW mal wieder rein, und hoffe das es damit geht.

Code würde ich ja poste, aber leider muss ich alles im drecks VB proggen
Wieso VB, der Prof mit dem ich das Projekt zusammen mache kann nur VB und hat halt die ganze scheisse in VB gemacht.

OK damit ihr mal besseren durchblick habt, was wir überhaupt machen:
Wir Programmieren schon seit anfang 2005 an einem Führerstand Simulator, also nen "Ich steuere Selbst ne Bahn" Simulator.
Das Projekt besteht aus mehreren Teilen:

- Tachozeugs in Flash
- Access Datenbank für Strecken informationen
- Die Bahnfahrt wird als Film dargestellt wo wir die entscheiden welches Bild dargestellt wird.
- Signalfilm über dem Bahn Film darüber, welches die orig. Signale ersetzt und durch Polygone dargestellt wird.

Unsere momentane Lösung:

VB Projekt >
Form >
mmTimer (Thread based Timer) welches auf 40ms gesetzt ist.
imagebox für die Bahnfahrt wo momentan in dem mmTimer den Film als JPEG Bilder in echtzeit über die GDI+ lib lädt welches aber zulangsam ist. Welches Bild geladen wird, wird über Geschwindigkeit > Ort berechnet.
shockwave flash object für den Tachokram
30-40 andere imageboxen für die eigene Signale welches über Position, und grösse berechnet wird (sehr schlechte lösung)

Meine Aufgabe ist nun eine lösung zu finden, alle imageboxen in die Tonne zu treten und die genialen OpenGL API zu benutzen, da der momentane kram zu langsam ist und sogar dann anfängt das Shockwave Flash für die Tachos ruckelt.

Also den Bahnfilm welches momentan als Einzel JPEG Bilder besteht ca. 115.000 stück so schnellst wie möglich abzuspielen, so wies die grossen Medienplayer machen.

Was später noch dazukommt ist eine COM schnittstelle für Steuerung mit einem Pult wo man dann die Hebel welche momentan als Trackbar gemacht werden ersetzt.

Oh mein Gott. Ich habe nie gefragt.

Meine erhliche Meinung ist, dass ihr alles in OpenGL machen solltet. Es wird dann zwar nicht mehr so schön aussehen wie es evtl. jetzt auf den Bildern der Fall ist.
Aber ihr habt:
1. keine Probleme mit dem Dekomprimieren der Bilder.
2. wesentlich mehr flexibilität, da ihr nicht auf Bilder angewiesen seit.
3. ein recht kleines Projekt, da nicht unmassen an Bilder rumfliegen müssen.

Abgesehen davon wirkt es komplett in OpenGL wesentlich profesioneller als mit 115.000 Bildern. Allerdings dürfte das dann noch mal ein schöner batzen an arbeit sein.

Als andere Alternative könntest du auch generell kurze Videos machen und die mittels DirectShow abspielen. Also so ein kurzes Streckenstück, welches immer gelooped wird bis etwas anderes passieren muss. Könnte evtl. auch ganz gut gehen. (nur um nicht alle neu machen zu müssen)

Achja, wer ahnung mit VB und Pointer haben soll:
Wie mach ich ne Speicherfestgelegung wie das GetMem() in Delphi ?

Ich muss ja einmal wenn ich glTexSubImage2d verwenden will, leeren Speicher bem glTexImage2D geben und nach dem prinzip gehts im Vb nicih:



Achja, hier ist nen screenshot wie das momentane aussieht:
http://xenorate.com/final/ultrarofl.jpg



Ah den DirectShow weg kannste total knicken, wenn du da alle 40ms die Abspielgeschwindigkeit mittels IMediaSeeking festgelegst SetRate() dann hagt das hin und her

Hoert sich fuer mich eher so an als ob das gesamt Design der Anwendung noch etwas verbessert werden koennte. Hier mal mein Brainstorming....
Ich wuerde auch die Signale und den Tacho in OpenGL rendern. Da nun alles in einem Render Loop gezeichnet wird, wuerde ich diesen Timer abschaffen und halt so viele Frames wie moeglich rendern.

Der Pseudo Render Loop:


Das Laden und Dekomprimieren wuerde ich mit einem Producer/Consumer Pattern erledigen.
Das funktioniert etwa so:

Du hast 2 Semaphoren welche die Threads davor schuetzen aus dem gueltigen Bereich der Liste wegzulaufen, und eine Mutex welche den Zugriff auf die Liste beschraenkt.

Die eine Semaphore zaehlt die vorhandenen Bilder und die andere Semaphore die vorhandenen freien Plateze im FIFO.

Consumer:
GetNewJepg ruft jetzt einfach immer erst ein WaitForSingleObject auf die "vorhandenen Bilder" Semaphore auf, das wuerde den Render Thread solange blockieren bis ein Bild da ist. Falls ein Bild in der Liste ist geht es sofort weiter.

Mutex nehmen, Bilder aus der Liste nehmen, Mutex wieder freigben.

Die "freie Plaetze" Semaphore um eins erhoehen.

Producer:
Ein Thread der endlos nur Jpegs laedt und dekomprimiert. Am anfang in diesem Thread wird immer zuerst ein WaitForSingleObject auf die "freie Plaetze" Semaphore aufgerufen, das bewirkt dass der Thread solange schlaeft bis auch wirklich Platz vorhanden ist. Wenn Platz vorhanden ist:

Bild laden, dekomprimieren, Mutex nehmen und der Liste hinzufuegen, Mutex freigben.

Die "vorhandenen Bilder" Sempahore um eins erhoehen.

Da Semaphoren System Objekte sind, werden die Threads auch nur ausgefuert wann noetig. Und das ganze System muss nie auf irgend welche Timers warten sondern kann froehlich vor sich hin rendern.
Just my $0.02

kannst doch die bilder per programmstart laden, obwohl, wäre ein problem, weil das mächtig viele sind ...
man könnte auch zwischendurch ein paar bilder mehr laden, aber das wäre wohl auch nicht so schön aber die einzige Lösung die mir für das Problem einfällt, oder du lädts die bilder in ne avi und spielst die dann ab, nach dem abspielen kannst sie dann wieder löschen