JOGL - Mehr als nur ein Canvas - Texturpool

[Memphis]

Hallo

Ich möchte mehre GLCanvas nutzen die auf den selben Texturpool zugreifen.
Diese Verbindung hab ich geschafft, indem ich ein Canvas im Hintergrund nutze und allen anderen dann den Context vom Canvas mitgebe.

Jetzt wollte ich die Texturen im 1. Canvas laden. Dazu habe ich ihm eine Liste gegeben.
Wenn jetzt die Display-Methode aufgerufen wird, dann soll die Liste geladen werden.

Nur hab ich folgendes Problem, da das Canvas nirgends im Frame eingefügt ist, wird auch nie die Displaymethode aufgerufen.
Irgendwelche Aufrufe mit Display habe ich schon probiert.

Ich wollte nun Fragen ob jemand eine Idee hat was ich tun kann, bzw. ob die Variante mit dem Canvas im Hintergrund überhaupt sinnvoll ist oder ob es irgendeine bessere gibt.

Vielen Dank.

 

[Evil-Devil]

Sind die mehreren GLCanvas permanent zu sehen oder bilden sie lediglich mehrere Viewports ab? Bei letzteren würde ein einzelnes GLCanvas mit entsprechenden Viewports genügen.

Falls du wirklich einzelne GLCanvas Objekte benötigt könntest du sie im Shared Modus erstellen oder aber bei der Aktivierung als Current setzen.

Und deine Liste müsstest du unabhängig von der Verwendung schon selbst aufrufen

//edit:Shared GLCanvas

 

[Guest2]

Moin,

das GLCanvas muss sichtbar sein, sonst wird es nicht gehen. Definiere eines einfach als dein Haupt- GLCanvas und share alle anderen mit diesem.

Z.B. als Beispiel.

Gruß,
Fancy

 

[Memphis]

Das Problem ist, es ist manchmal keins sichtbar ist und manchmal sind es 3-4. Also fällt es mir schwer ein Hauptcanvas zu defenieren. Ich wollte ja gerade meine Texturen ein wenig kapseln. Das ganze soll der Texturmanager werden.

@Guest2, genau nach dem Beispiel hab ich es auch gemacht.

Gibt es denn eine Möglichkeit eine Textur auch ohne Gl-Context, also einfach so zu laden?

Zur Zeit lade ich meine Texturen mit TextureIO. Da muss jedoch immer der GL-Context da sein.

 

[Evil-Devil]

Du könntest deine Texturen über einen PBuffer laden, nur weiß ich nicht ob man den mit einem GLCanvas sharen kann.

 

[Guest2]

Das Problem ist, es ist manchmal keins sichtbar ist und manchmal sind es 3-4. Also fällt es mir schwer ein Hauptcanvas zu defenieren. Ich wollte ja gerade meine Texturen ein wenig kapseln. Das ganze soll der Texturmanager werden.

Hast Du mal versucht, was passiert, wenn Du eines Deiner GLCanvas als Hauptcanvas definierst, dieses kurz anzeigen lässt, dann die Texturen einspielst und anschließend wieder unsichtbar machst, bis das Du es wieder brauchst?

Der GL Kontext sollte bei einem GLCanvas bis zu einem dispose() gültig bleiben.

Der von Evil-Devil erwähnte PBuffer geht natürlich auch (ein 1x1 Pixel PBuffer reicht vollkommen).

Grundsätzlich gilt bei allen Varianten, in dem sich Ressourcen über einem GL Kontext hinweg geteilt werden, das der Zugriff auf diese Ressourcen langsamer ist, als wenn der Kontext eigenständig wäre.

Gibt es denn eine Möglichkeit eine Textur auch ohne Gl-Context, also einfach so zu laden?

Zur Zeit lade ich meine Texturen mit TextureIO. Da muss jedoch immer der GL-Context da sein.

Ohne GL Kontext bekommst Du Deine Texturen nur bis in den Hauptspeicher. Um sie in den Speicher der Grafikkarte zu bekommen, brauchst Du einen GL Kontext.

Ich mache das meistens in etwa so.

Bei meinen GL Programmen hatte ich die Idee auch schon, meine Texturen in einem PBuffer auszulagern, jedoch aufgrund der Nachteile wieder verworfen. Insbesondere da der GL Kontext eines GLCanvas bis zum dispose() gültig bleibt. Bei einem GLJPanel wird der Kontext wesentlich öfter verworfen, so dass es dort echt zum Problem werden kann.

Gruß,
Fancy

 

[Nardian]

hi,

es wurde ja schon in nem anderen thread erwähnt, dass ich einfach nur die natives durch "meine" ersetzten soll (win_amd_64) ... nur find ich keine (funktionierende) version... mach ich was falsch oder wie kommts dass ich immer nur

Exception in thread "main" java.lang.UnsatisfiedLinkError: no nativewindow_jvm in java.library.path

bekomme, wenn ich die natives durch eben meine ersetzte?

/edit:
hmm... die exception kommt daher, da ich einfach diese dll nich habe... aber ich die fehlt auch in der zip oO
ich nehme doch einfach mal an, dass ich hier richtig bin, wenn ichs von hier sauge, oder?
Index of /deployment/autobuilds/jogl-2010-07-08_08-27-31/build

 

[Guest2]

Moin,

die JARs sind zwar Plattformunabhängig, so das die natives bei Bedarf einfach ausgetauscht werden können, jedoch sind die natives auch abhängig von der Version der JARs. Wenn Du die ganz aktuellen aus dem Link von Dir nutzen willst, musst Du auch die JARs kopieren.

Du brauchst:

Ins lib:
gluegen-rt.jar
jogl.all.jar
nativewindow.all.jar
newt.all.jar

Ins native:
gluegen-rt.dll
newt.dll
nativewindow_awt.dll
jogl_desktop.dll

Anschließend musst Du noch ein paar Importanweisungen korrigieren, da Buffers, Animator und FPSAnimator nun in anderen Paketen liegen (com.jogamp...).
(btw. wtf warum nennen die das eigentlich com.jogamp wenn deren Seite jogamp.org ist? Und jogamp.com ist noch nicht mal registriert?)

Gruß,
Fancy