Da gab es doch mal einen Befehl OGL, aber ich finde den nicht mehr.
Über Google komm ich nur auf nicht-hilfreiche Antworten dass Multithreading bei OpenGL nichts bringt und man es deshalb erst nicht versuchen sollte. Mir fehlt der richtige Google-Suchbegriff und stehe deshalb auf dem Schlauch.
Hintergrund der Geschichte ist, dass Google den Android Entwicklern Multithreading aufzwingen will indem in der Android OGL ES API der OGL Kontext in einem eigenen Thread erstellt wird, und der ruft dann in einer Schleife immer nur eine Methode des übergebenen Listeners render() auf.
Das macht mir meine Programmarchitektur aber schön kaputt.
Deshalb ist der Plan den Thread direkt wieder zu stoppen und OpenGL auf meiner eigenen Thread Architektur laufen zu lassen.
Hehe… glücklicherweise hast du mich und ich hatte vor kurzem das Problem, OGL aus verschiedenen Threads heraus aufzurufen und das ohne zu wissen, ob auf diesen bereits ein OGL-Kontext existiert oder nicht. Ich habe mir dafür dann sowas gebaut:
class PbufferMap {
private static final long IDLE_TIMEOUT = 5000;
private static final long IDLE_TIMEOUT_NANOS = IDLE_TIMEOUT * 1000000;
private static final ResourceSet REFERENCE = new ResourceSet(null);
private static final PixelFormat FORMAT = new PixelFormat();
private static final ThreadSet CACHE = new ThreadSet();
private static int cnt;
}[/code]
Mit aquire kann man einen OGL-Kontext für den laufenden Thread erstellen und ggf. initialisieren, wenn true zurückgegeben wird. Mit release gibt man den Kontext wieder frei,
release zerstört jedoch den Kontext nicht gleich, sondern wartet 5 Sekunden Inaktivität ab.
Ich denke mal, für den Anfang genügt das so, aber es läßt sich sicher noch verbessern.
Wobei ich sagen muss, dass das echt kompliziert ist. Und dann der Umweg über den Pixelbuffer für jeden Thread?
Das wird teuer auf Android.
Puh. Ich lass das mal als Antwort stehen, suche aber noch weiter nach besseren Möglichkeiten.
Dann mal einen Schritt zurück (da ich keine Ahnung von den Android-GL-spezifika und anderen Dingen habe, mögen die Fragen aber naiv klingen) :
In welcher Hinsicht geht deine Programmarchitektur damit kaputt? (Eine “init()”- und eine “render()”-Funktion gibt’s ja doch meistens…)
Kann man da überhaupt so einhaken, dass man den Thread selbst festlegen kann? Je nachdem, wie strikt die das zugenagelt haben, könnte da ja zumindest Reflection nötig sein, falls es überhaupt geht…
Richtig. Aber mein portiertes Programm habe ich damals mit Hinsicht auf Multithreading geschrieben. Der Architektur zugrunde - und darauf aufbauend - liegt ein experimenteller etwas anderer Ansatz eines Workerthreadpools (der fast vollständig auf synchronised verzichtet).
Jetzt müsste ich das großflächig umschreiben um Fremd-Erzeugte-Threads dort einzubinden über die ich zudem keine vollständige Kontrolle habe was Erzeugung, Pausieren und Stoppen angeht.
Damals hatte ich mal mit JOGL immer eine Methode aufgerufen um den Thread einfach zu ändern.
Im Moment aber schaue ich mir den SourceCode an um manuell einen Kontext zu erzeugen