Mozilla aktiviert Multiprozess-Architektur in Firefox Nightly
Mozilla arbeitet bereits seit geraumer Zeit an einer Multiprozess-Architektur für Firefox. In der Nightly-Version von Firefox ist der neue Modus ab sofort standardmäßig aktiviert.
Mozilla macht große Fortschritte bei der Entwicklung der Multiprozess-Architektur von Firefox (Electrolysis, e10s). Zwar liegt noch eine ganze Menge Arbeit vor Mozilla, doch ist man mittlerweile so weit, dass Firefox ab dem heute erscheinenden Nightly-Build des kommenden Firefox 36 standardmäßig in diesem Modus laufen wird.
Die standardmäßige Aktivierung betrifft jedoch lediglich die Nightly-Version. Sobald Firefox 36 in die Aurora-Phase übertritt, wird e10s dort nicht mehr standardmäßig aktiviert sein. In den letzten Wochen und Monaten wurden zwar viele Fortschritte erzielt, nichtsdestominder müssen Nightly-Nutzer noch damit rechnen, dass einige Dinge noch nicht funktionieren, insbesondere was die Kompatibilität mit Add-ons betrifft. Wer genug getestet hat und e10s wieder deaktivieren möchte, kann dies über die Einstellungen tun, dort ist direkt die erste Einstellung für das Aktivieren respektive Deaktivieren von e10s verantwortlich.
[lightbox style=“modern“ image_path=“https://www.soeren-hentzschel.at/wp-content/uploads/e10s-einstellung.png“ popup=“https://www.soeren-hentzschel.at/wp-content/uploads/e10s-einstellung.png“ link_to_page=““ target=““ description=““ size=“two_col_small“]
Sören Hentzschel ist Webentwickler aus Salzburg. Auf soeren-hentzschel.at informiert er umfassend über Neuigkeiten zu Mozilla. Außerdem ist er Betreiber von camp-firefox.de, der ersten Anlaufstelle im deutschsprachigen Raum für Firefox-Probleme aller Art. Weitere Projekte sind firefox.agenedia.com, firefoxosdevices.org sowie sozone.de.
Musste ich gleich wieder abschalten. Graphikprobleme, auseinander gezogene Bilder. Auch hier auf dieser Page mit dem screenshoot oben und unten der blaue Abschnitt sah auch aus wie durch den Reißwolf gezogen. E10S abgeschaltet und alles schön. Zweites Profil das selbe…also unter meiner Hardware noch nicht nutzbar.
Der Grafikkartentreiber ist aktuell?
Also aktueller gehts nicht und das Problem ist ja auch nur mit E10S.
Adapter Description AMD Mobility Radeon X1600
Adapter Drivers atiumdagB atidxx32 atiumdva
Adapter RAM Unknown
Device ID 0x71c5
DirectWrite Enabled false (6.3.9600.17111)
Driver Date 6-8-2014
Driver Version 14.200.0.1
Das kann, denke ich, schon sein, dass ein Problem mit der Hardwarebeschleunigung nur mit e10s auftritt, denn dahinter steckt ein so großer Umbau, dass einfach so viele Bereiche des Browsers berührt werden, dass ich nichts für unmöglich halte. 😉 Grundsätzlich können solche Darstellungsfehler eigentlich nur mit der Hardwarebeschleunigung zusammenhängen. Mir fällt zumindest kein Szenario ein, in welchem Firefox ansonsten solche Probleme haben könnte. Dass der Treiber bereits aktuell ist, ist insofern ärgerlich als dass das ein naheliegender Lösungsansatz gewesen wäre, der damit wegfällt. Ein Test mit deaktivierter Hardwarebeschleunigung wird wohl wenig bringen, da das automatisch e10s mit deaktiviert. Vielleicht wäre es gut, wenn du ein Ticket auf Bugzilla erstellen könntest inkl. der hier bereits geposteten Grafikkarten-Daten. Vorweg: Ich weiß nicht, ob es bereits ein Ticket dazu gibt.
musste ich sofort wieder abschalten.
von meinen 7 apptabs laden 2 überhaupt nicht, der FF graut aus, prozess steht und muss abgeschossen werden.
graka ist immer aktuell.
hab das auch detalliert als rückmeldung geschildert.
und es ist wieder mal der innoreader mit feedcounter der theater macht. und den brauch ich.
ausserdem erscheinen alle apptabs mit sperrzeichen (tabmixplus)
habe aber nichts gesperrt.
anregungen?
Direct2D aktiviert true
DirectWrite aktiviert true (6.2.9200.16571)
Geräte-ID 0x6738
GPU #2 aktiv false
GPU-beschleunigte Fenster 1/1 Direct3D 11 (OMTC)
Karten-Beschreibung AMD Radeon HD 6800 Series
Karten-RAM 1024
Karten-Treiber aticfx64 aticfx64 aticfx64 aticfx32 aticfx32 aticfx32 atiumd64 atidxx64 atidxx64 atiumdag atidxx32 atidxx32 atiumdva atiumd6a atitmm64
Subsys-ID 23051787
Treiber-Datum 10-4-2014
Treiber-Version 14.301.1004.0
Vendor-ID 0x1002
WebGL-Renderer Google Inc. — ANGLE (AMD Radeon HD 6800 Series Direct3D9Ex vs_3_0 ps_3_0)
windowLayerManagerRemote true
AzureCanvasBackend direct2d
AzureContentBackend direct2d 1.1
AzureFallbackCanvasBackend cairo
AzureSkiaAccelerated 0
Wird von TMP die letzte Dev-Version genutzt?
https://addons.mozilla.org/en-us/firefox/addon/tab-mix-plus/versions/
ja, die letzte dev: 0.4.1.6pre.141025a1 vom 26.oktober aus dem forum.
die hat bis vor dem update eben tadellos funktioniert.
Dann keine Ahnung. TabMixPlus macht auch ohne e10s schon oft genug Probleme in Nightly-Versionen, weil das eine so komplexe Erweiterung ist, welche auch noch einen Bereich von Firefox tangiert, in dem sich auch bei Firefox so viel tut. Ich würde nicht drauf wetten, dass das Add-on schon zu 100 Prozent bereit für e10s ist. Wissen tu ich es aber nicht.
Was wurde eigentlich aus dem „Rapid“ Release Modell? 6 Wochen pro Release haben wir, OK. Aber Rapid im Sinne von Rapid Development kann man es ja wohl nicht nennen.
Was ich meine:
Wir haben jetzt FF33, bis FF36 sind es über 4 Monate, aber auch da wird das Feature noch deaktiviert sein. In Entwicklung überhaupt ist es wie lange? Seit 2009 mit Unterbrechungen? Browser in moderner Form gibt es seit ca. 20 Jahren (mitte 90er, Netscape seit 1994) und Mozilla doktort über 20% der Zeit (4/20 Jahren!) an einem einzigen Feature herum? Bzw. sogar über 40% der Zeit, wenn man nur die Zeit vom Firefox betrachtet (FF gibt es seit 2004, also 4/10 Jahren).
Mit 64 Bit das gleiche.
Von Rapid spüre ich hier rein gar nichts. Klar ist es ein großes Feature, das gut getestet werden will. Aber ich sehe hier absolut kein sinnvolles Verhältnis. Wie kann denn ein einziges Feature über 1/3 der Gesamtentwicklungszeit einnehmen, obwohl das Produkt als solches bereits hervorragend läuft? Und mit jedem weiteren Monat wird dieses Verhältnis schlechter.
Oder anders: Wieso haben die es damals geschafft einen kompletten Browser (mit Add-On-System, multiplatform, multilingual, stabil, schlank, etc.pp.) in 5 Jahren zu entwicklen, brauchen jetzt aber für ein einziges Feature mindestens genauso lange?
Schreiben die den kompletten Browser neu?
Bug 1095781 ist erstellt.
@foobar:
Du hast glaube ich eine falsche Vorstellung davon. Rapid Release bedeutet absolut nicht, dass Features in der Entwicklung maximal sechs Wochen benötigen. Rapid Release bedeutet nicht mehr und nicht weniger als dass alle sechs Wochen eine neue Version mit Neuerungen erscheint.
Wenn du schreibst, Mozilla würde daran seit 2009 mit Unterbrechungen arbeiten, vermittelt das ein vollkommen falsches Bild. Mozilla arbeitet seit April 2013 wieder aktiv daran, während es zwischen 2009 und 2011 bisschen Arbeit daran gab und dann als Projekt komplett stillgelegt wurde. Im Mai 2014 wurden die Ressourcen für dieses Projekt erhöht, seit dem ist es erst ein Projekt höchster Priorität.
Darüber hinaus ist e10s kein Feature, welches man entwickelt und dann in den Browser steckt, e10s erfordert einen Umbau des kompletten Browsers. 40% der Zeit ist außerdem eine Milchmädchenrechnung. Mal abgesehen von dem, was im vorherigen Abschnitt steht, kann man so überhaupt nicht rechnen, weil das ja auch eine Frage dessen ist, wie viel Personal wofür zur Verfügung steht. Man kann das nicht auf eine Stufe stellen, wenn einer an etwas arbeitet oder wenn 500 an etwas arbeiten (um zwei unwahre Extreme zu nennen).
Nö, daran ist überhaupt nichts gleich. An Windows 64-Bit für Windows wurde bis vor kurzem überhaupt nicht aktiv gearbeitet.
Rapid Release ist ein Release-Modell und hat überhaupt keine Bedeutung für die Entwicklungsdauer von irgendetwas. Und nochmal: es ist kein Feature wie jedes andere, es ist ein kompletter Browserumbau. Und ebenfalls nochmal: Ein Drittel der Gesamtentwicklungszeit entspricht kein bisschen der Realität, so kann man nicht rechnen.
Es ist etwas vollkommen anderes, ob man einen Browser von null entwickelt und keine Rücksicht auf irgendetwas nehmen muss oder ob einen bestehenden Browser komplett umbauen muss und vor allem so große Rücksicht auf Add-on-Kompatibilität nehmen muss, wie Mozilla es muss. Wie du auf fünf Jahre kommst, ist mir unklar.
Nicht neu, sondern um. Aber ja, den kompletten Browser.
@TheRave:
Danke für das Anlegen des Bugs und das Nennen der Bugnummer.
Ist jemand bekannt, warum E10S seit kurzem deaktiviert wurde, wenn der IME (Input method editor) aktiviert ist. Im MozillaWiki – Electrolysis und in Bugzilla konnte ich keinen Grund dafür finden.
Hier ist das Ticket zur Deaktivierung:
https://bugzilla.mozilla.org/show_bug.cgi?id=1063669
Das ist ein Tracking-Bug für IME + e10s:
https://bugzilla.mozilla.org/show_bug.cgi?id=1041185
Die Abhängigkeiten davon geben Aufschluss darüber, was noch fehlt (keine Garantie auf Vollständigkeit).
Wobei Mozilla die Tracking-Bugs gar nicht mehr für e10s nutzt, sondern stattdessen Bugs einzelnen Meilensteinen zuordnet, möglicherweise ist diese Liste also wirklich nicht mehr aktuell. Einen besseren Link habe ich aber nicht.
Vielen Dank für die sehr schnelle Antwort.
Den Bug habe ich gesehen, aber nicht mit der Deaktivierung in Beziehung gebracht, da er zu lange zurückliegt und E10S bis vor wenigen Tagen noch aktiviert war.
Da hier IME nicht aktiv ist, kann ich da leider weder was anderes sagen noch das bestätigen. Wenn dich der Grund interessiert und Englisch keine Hürde ist, dann wäre es vielleicht eine Idee, bei Mozilla im IRC mal nachzufragen, es gibt einen Kanal #e10s.
Habe im IRC nachgefragt, eine Antwort war, dass es an Bug ‚1063669‘ liegt, dann kam aber die Antwort, dass er aber im Status: RESOLVED FIXED ist.
Für diesen hervoragenden Blog
Vielen Dank
有難うございます
thank you very much
P.S.
Soll ich weitere Ergebnisse, wenn ich welche bekomme, hier festhalten?
Lösung um E10S zu aktivieren, wenn IME (Input method editor) aktiviert ist:
browser.tabs.remote.autostart = true (default: false)
browser.tabs.remote.autostart.1 = false (default: true)
@Hauro:
Danke für die Worte und gerne. 🙂
Klingt nach einem „Trick“, aber solange es funktioniert. 😀