Der Phoenix-Viewer nutzt wegen der Auflagen von Linden Lab keine Emkdu.DLL mehr und kommt mit OpenJPEG 1.3.0 als dafür zuständige Bibliothek daher. Das macht sich im Vergleich zum alten Emerald in einem langsameren Rezzen der Texturen bemerkbar.
Nun ist Phoenix dergestalt umgebaut worden, dass er das Rezzen nur noch mittels OpenJPEG vornimmt, auch wenn LLkdu vorliegen sollte, und sonst gar nicht. Das war eine der alten Forderungen von Seiten Linden Labs an die Emerald Entwickler, ich habe es mit allen möglichen LLkdus probiert, es funktioniert nicht.
Nun kann man mit einem kleinen Trick Phoenix dennoch zu schnelleren Rezzingzeiten überreden. Die Version 1.3.0 von OpenJPEG nämlich ist nicht mehr aktuell und Imprudence kommt mit der deutlich schneller arbeitenden Version 1.4.0.565 daher.
Also lädt man unter Windows sich einfach zuerst Imprudence herunter (z.B. die 1.3.0 RC2) und installiert diesen. Aus dem Programmverzeichnis von Imprudence kopiert man dann die Datei OPENJPEG.DLL in das Programmverzeichnis vom Phoenix-Viewer und startet diesen danach.
Wenn alles geklappt hat, dann sieht man im Menü „Hilfe“ unter „Über Phoenix Viewer“ folgendes, wichtig ist dabei der farbig eingekastete Bereich:
In dem muss als Runtime „1.4.0.565“ stehen, damit nutzt nun Phoenix Viewer die neuere Bibliothek und sollte schneller arbeiten.
wäre llkdu nich besser? und ie bekommt man ihn dazu das der damit läuft?
Wie ich schon schrieb:
Ohne eigene Änderung am Quellcode und eigenes Kompilieren des Viewers geht da gar nichts.
Was hat LL gegen das schnelle rezzen? Und warum packt Phoenix diese OPENJPEG.DLL nicht gleich selber rein?
Vielleicht wollen sie es als“Qualitätsmerkmal“ lieber für den eigenen Viewer behalten und wieso Phoenix das nicht macht – keine Ahnung.
naja, ich weiss nicht ob ich das richtig interpretiere:
http://www.phoenixviewer.com:3000/projects/phoenixviewer/repository/revisions/153/diff
61 61 //Loads the required „create“, „destroy“ and „engineinfo“ functions needed
62 62 void LLImageJ2C::openDSO()
63 63 {
64 // Do not attempt to load any j2cdecoder/j2cencoder library
65 // use openjpeg all the time.
66 return;
64 67 //attempt to load a DSO and get some functions from it
65 68 std::string dso_name;
66 69 std::string dso_path;
aber für mich sieht das schon nach dem richtigen ansatz aus 😕
Das wird es wohl sein, nur hat längst dann nicht jeder das nötige Wissen, ein eigenes Binary zu kompilieren und von Seiten des Phoenixteams wird es so ein Binary kaum geben.
der gute alte emerald crashte viell. so ca 3-4 mal im monat, phoenix mehrmals täglich. dann sehe ich mich aoft nach neustart als weisse wolke. abhilfe: neustart mit dem sl-viewer 2 – wobei ich dann alle attachments verliere und meine ava wieder neu einrichten muss –
was kann da los sein ? (Win XP home – aktuell und ein guter rechner im feb. neu angeschaff)