Google Earth Web-Version: 3D Darstellung bei Navigation nicht flüssig...

    Firefox-Version
    91.0.2
    Betriebssystem
    Win10

    Hallo,

    In der Google Earth Web-Version läuft die 3D-Navigation über die Tastatur (Cursor-Tasten) unter FF91 längst nicht so geschmeidig, wie unter unter Chrome/Edge. Das heißt nicht, dass die Geschwindigkeit im FF jetzt so wäre, dass man es nicht mehr vernünftig bedienen könnte, aber es ist eben 'ruckeliger'. Mein Rechner ist sicher leistungsstark genug, um diese doch recht minimalen Anforderungen an die 3D Performance zu bewältigen. Außerdem läuft es ja auch wie gesagt unter Chrome absolut flüssig. Auch in der Nightly mit eingeschalteter WebGPU-Unterstützung, kein Unterschied.

    Ist das bei euch auch so?

    Mal zum Testen den gleichen Startpunkt:

    Google Earth

    Könnte es sein, dass Google hier unterschiedliche Versionen an die jeweiligen Browser übermittelt (Beim FF steht oben "Derzeit wird eine experimentelle Version von Google Earth ausgeführt")? Frage mich, ob der Grund dafür eher ein technischer oder eine bewusste Benachteiligung anderer Browser ist? Oder ist die FF WebRender Implementierung nicht so leistungsfähig, wie unter Chrome/Edge? :/

  • Zur hilfreichsten Antwort springen

    Ja, danke fürs Testen...

    Nur werden ja unter Windows, MacOS und Linux z.T. unterschiedliche Engines für die Grafikdarstellung benutzt (Direct2D/3D, Metal, OpenGL usw.), daher würde mich vor allem natürlich eine zusätzliche Aussage zu Win10 interessieren.

    Bin auch gar nicht sicher, ob es (nur) am Grafik-Rendering liegt, da alle FF-Prozesse zusammengenommen, die Performance Auslastung meiner CPU (beim Bewegen über Prag mit den Cursor-Tasten) zeitweilig auf über 80% bringen. Bei Chrome ist die Auslastung genauso hoch, aber hier ist die Darstellung flüssig. Daher vermute ich, dass die Berechnungen in der JS-Engine wohl sehr rechenintensiv sind und FF entweder einen anderen Code bekommen hat oder diesen anders interpretiert... :/

    Einmal editiert, zuletzt von BrokenHeart (3. September 2021 um 17:39)

    Zitat von 2002Andreas

    Das kann ich hier auch für Chrome bestätigen, läuft weicher würde ich es mal nennen.

    Auch dir danke ich fürs Testen/Bestätigen...

    Richtig 'rucklig' wird es eigentlich dann unter FF, wenn er Inhalte aus dem Cache/Web nachladen muss ( Prozentanzeige < 100%, unten links). Chrome scheint sich auch beim Nachladen von Inhalten (auch die, die er noch nicht im Cache hat) unbeeindruckter zu zeigen...

    • Hilfreichste Antwort

    Ich hätte da einen Verdacht, was definitiv ein Performance-Flaschenhals sein kann, wenn die Single-Thread-Performance des Endgeräts nicht so berauschend ist: Google Earth ist eine multi-threaded WebAssembly-Anwendung, nutzt in Firefox aber nur einen Thread. Stelle über about:config dom.postMessage.sharedArrayBuffer.bypassCOOP_COEP.insecure.enabled auf true. Beachte, dass dies nur in Firefox Nightly sowie in der Firefox Developer Edition möglich ist (Mozilla hat hier noch Sicherheitsbedenken). Ändere außerdem den User-Agent für Google Earth (bitte nur dafür) auf den von Chrome, da Google auch mit geänderter Einstellung nur die Single-Thread-Version an Nutzer von Firefox ausliefert. Nur den User-Agent zu ändern, aber nicht die Option in Firefox, wird dazu führen, dass Google Earth überhaupt nicht mehr funktioniert.

    Hallo Sören,

    vielen Dank! Die vorgeschlagene Änderung hat definitiv die Performance verbessert. :thumbup:

    Ich konnte jetzt, nach einem kurzen Test, keinerlei Unterschiede mehr zur Chrome-Performance feststellen.

    Aber das bei einem "Intel Core i5-8400" von 2018 die "Single-Thread-Performance des Endgeräts nicht so berauschend ist" möchte ich jetzt fast nicht glauben :/ .

    Die Maximale SingleCore-Taktfrequenz ist laut Intel 4GHz(Turbo-Boost).

    Wenn ich die Navigation in Google-Earth mit FF91 starte, werden mir für jeden Kern 3,811GHz(Turbo-Boost) angezeigt.

    In der Nightly sind es bei jedem Kern 2,908GHz.

    OK, der Prozessor besitzt im Gegensatz zu den i7-Modellen kein Hyperthreading und daran wird es dann wohl liegen... :(

    3 Mal editiert, zuletzt von BrokenHeart (3. September 2021 um 23:44)

  • BrokenHeart 3. September 2021 um 23:46

    Hat einen Beitrag als hilfreichste Antwort ausgewählt.

    Schön, dass die wahrscheinliche Ursache damit gefunden ist. Leider ist wohl nicht davon auszugehen, dass das so bald auch ohne diesen lästigen Umweg mit maximaler Performance laufen wird.

    Zitat von BrokenHeart

    Aber das bei einem "Intel Core i5-8400" von 2018 die "Single-Thread-Performance des Endgeräts nicht so berauschend ist" möchte ich jetzt fast nicht glauben :/ .

    Naja, ist ja alles relativ. Legt man die Benchmark-Zahlen von cpubenchmark.net zu Grunde, kommt der Intel Core i5-8400 auf einen Single-Core-Score (PassMark) von 2.410, was jetzt nicht schlecht ist, aber der Apple M1 kommt auf 3.779. Und das ist schon ein deutlicher Unterschied in der Performance. Das ist jetzt natürlich nur ein Benchmark, der nicht unbedingt die Realität für Google Earth abbilden muss. Da kann der Unterschied auch geringer ausfallen - oder höher. Was ich nur mit Sicherheit sagen kann, ist eben, dass ich trotz Single Thread-Version von Google Earth keinen Unterschied zu Chrome wahrnehmen kann. Meine Formulierung "nicht berauschend" darf gerne explizit auf diesen Fall bezogen werden. Für die durchschnittliche Website oder auch Anwendung auf dem Computer ist die Performance mit Sicherheit mehr als ausreichend. ;)

    Zitat von BrokenHeart

    Die Maximale SingleCore-Taktfrequenz ist laut Intel 4GHz(Turbo-Boost).

    Wenn ich die Navigation in Google-Earth mit FF91 starte, werden mir für jeden Kern 3,811GHz(Turbo-Boost) angezeigt.

    Die Taktfrequenz ist ähnlich wie die Megapixel-Zahl von Kameras - hohe Zahlen lesen sich gut, haben aber nicht die große Bedeutung. Das ist nur ein Faktor für die Performance und bei weitem nicht alleine für die Leistung verantwortlich. Nicht grundlos gibt es nun seit Jahren schon bei der Taktfrequenz keinen bedeutenden Sprung mehr, und trotzdem werden die CPUs immer schneller. ;)

    Zitat von Sören Hentzschel

    Naja, ist ja alles relativ.

    Sieht so aus ;) . Hatte mich irgendwann mal von den i7K-Stromfressern verabschiedet und mich bewusst für einen "Mittelklasse"-Prozessor entschieden (TDP 65W vs. 95W). Wie gesagt, das war 2018. Da die allermeisten Spiele bzw. 3D-Anwendungen heute eh Multithreaded sind, ist das auch nicht so tragisch, dass der Prozessor kein Hyperthreading besitzt.

    Zitat von Sören Hentzschel

    Schön, dass die wahrscheinliche Ursache damit gefunden ist. Leider ist wohl nicht davon auszugehen, dass das so bald auch ohne diesen lästigen Umweg mit maximaler Performance laufen wird.

    Warum nicht? Ist man, was WebAssembly oder Multithreading angeht, noch nicht so weit bei Mozilla oder was ist der Grund, warum das nicht in absehbarer Zeit in der Release-Version verfügbar ist?

    Kann ich dom.postMessage.sharedArrayBuffer.bypassCOOP_COEP.insecure.enabled für alle Nightly-Profile drin lassen oder ist das nicht ratsam?

    Zitat von BrokenHeart

    Hatte mich irgendwann mal von den i7K-Stromfressern verabschiedet und mich bewusst für einen "Mittelklasse"-Prozessor entschieden (TDP 65W vs. 95W).

    Ich weiß, dass das jetzt ein wenig vom Thema wegführt, aber ich möchte an dieser Stelle nicht unerwähnt lassen, dass der Apple M1, trotz der so deutlich besseren Leistungsbewertung eine maximale TDP von gerade einmal 15W besitzt. Die Information mag dir jetzt nichts bringen, aber ich erwähne es, weil doch schön zu sehen ist, dass es also technisch möglich ist, bei der Energieeffizienz noch viel mehr herauszuholen - hoffentlich auch in nicht zu ferner Zukunft für Intel. Die müssen echt aufpassen, dass sie den Anschluss nicht komplett verlieren, nachdem erst Apple technisch deutlich an Intel vorbeigezogen ist und jetzt auch noch Google mit seinen nahezu unendlichen finanziellen Mitteln in die Entwicklung von Prozessoren für Desktop-Systeme eingestiegen ist.

    Zitat von BrokenHeart

    Warum nicht? Ist man, was WebAssembly oder Multithreading angeht, noch nicht so weit bei Mozilla oder was ist der Grund, warum das nicht in absehbarer Zeit in der Release-Version verfügbar ist?

    Kann ich dom.postMessage.sharedArrayBuffer.bypassCOOP_COEP.insecure.enabled für alle Nightly-Profile drin lassen oder ist das nicht ratsam?

    Firefox unterstützt grundsätzlich WebAssembly und Multithreading, aber mit dem genannten Schalter wird eine Einschränkung aufgehoben und da hat Mozilla Sicherheits-Bedenken. Ich kann darüber auch nichts im Detail sagen, weil das ein sehr kompliziertes Thema ist, bei dem es auch schon so manches Hin und Her gab, und ich von WebAssembly auch ganz weit entfernt bin. Aber dass dieser Schalter eingeführt worden ist, ist jetzt auch schon einige Zeit her und ich konnte keine Information finden, die darauf hindeutet, dass da Änderungen anstehen. Und was das Thema Änderung des User-Agents angeht, konnte ich wahrnehmen, dass Mozilla wohl nicht erst einmal mit Google Kontakt aufgenommen hat, aber Google das ziemlich egal zu sein scheint.

    Ok, danke für die Infos. Ist ja nicht so schlimm, werde ich halt Google Earth weiter in Chrome starten, sonst würde der Google-Browser ja total sinnlos in der Gegend rumliegen...oder alternativ in einem eigenen Profil für die Nightly.

    Einmal editiert, zuletzt von BrokenHeart (4. September 2021 um 00:47)