Roadmap für die Desktopversion

[klink]

Mozillas Roadmap für die Desktopversion ist auf Sand geschrieben z.B.
-der Downloadmanager sollte schon mit FF4 kommen.
-die 64bit Version sollte auch mit FF4 kommen, dann mit FF5, dann Ende 2011.
-Electrolysis (Multi-Prozess-Architektur für den Firefox) sollte auch mit FF4 kommen, das Projekt wurde vor 4 Monaten eingestellt.

Den PDF-Betrachter kann man bereist als Jetpack Add-on ausprobieren
Stable Version:
https://addons.mozilla.org/de/firefox/addon/pdfjs/
Development Version:
http://mozilla.github.com/pdf.js/extensions/firefox/pdf.js.xpi

[Erunno]

klink schrieb:
--------------------------------------------------------------------------------
> Mozillas Roadmap für die Desktopversion ist auf Sand geschrieben z.B.
> -der Downloadmanager sollte schon mit FF4 kommen.

Das Feature wird von einem Freiwilligen in seiner Freizeit entwickelt. Wenn man sich die Anzahl der Iterationen und abhängigen Bugs anschaut, dass das Feature nicht trivial ist. Nicht, dass ich hier Mozilla zu stark in Schutz nehmen möchte. Sie hatten schon immer das Problem, tolle Ideen zu haben und bei der Umsetzung zu scheitern.

> -die 64bit Version sollte auch mit FF4 kommen, dann mit FF5, dann Ende
> 2011.

Und was genau versprichst Du dir jetzt davon genau, außer dass hauptsächlich die JS Engine in einigen synthetischen Benchmarks etwas schneller läuft?

> -Electrolysis (Multi-Prozess-Architektur für den Firefox) sollte auch mit
> FF4 kommen, das Projekt wurde vor 4 Monaten eingestellt.

Das stimmt nicht. Elektrolysis wurde auf Eis gelegt, um kurz- und mittelfristigen Zielen den Vorrang zu geben, die man eh unabhängig von Electrolysis hätte angehen müssen (kein I/O auf dem Hauptthread, Zeichengeschwidigkeit verbessern, SQL Schemata und Queries optimieren, neue Cache-Architektur, etc.). Diese Arbeiten sollen im 3. oder 4. Quartal abgeschlossen sein, und danach will man sich wieder auf Electrolysis besinnen. Keines der genannten Probleme wäre durch Electrolysis gelöst worden. Sie haben aber dennoch erheblichen Einfluss auf die Geschwindigkeit der Oberfläche und der Aufwand ist geringer und besser planbar, als für einen kompletten Umbau der Browser-Architektur.



1 mal bearbeitet, zuletzt am 13.02.12 14:53 durch Erunno.

[Xstream]

sry aber so lange wie electrolysis schon im gespräch ist wird das mit jeder verschiebung unwahrscheinlicher dass es jemals kommt. imho ist electrolysis absolut unumgänglich um die zukunft von firefox zu sichern.

[klink]

Erunno schrieb:
--------------------------------------------------------------------------------
> Nicht, dass ich hier Mozilla zu stark in Schutz
> nehmen möchte. Sie hatten schon immer das Problem, tolle Ideen zu haben und
> bei der Umsetzung zu scheitern.
Teilweise verläuft die Entwicklung ziellos bzw. Chaotisch, dass betrifft vor allem das UX-Team, es werden Neuerungen fast fertig entwickelt und dann wieder verworfen, so dass teilweise Monatelange Arbeit umsonst war.

> Und was genau versprichst Du dir jetzt davon genau, außer dass
> hauptsächlich die JS Engine in einigen synthetischen Benchmarks etwas
> schneller läuft?

Zum einen gibt es Für Linux und Mac Native 64bit Versionen und zum anderen ist eine Native 64bit Anwendung sicherer und mit Optimierung kann man auch deutliche Performance gewinne machen.

> Das stimmt nicht. Elektrolysis wurde auf Eis gelegt, um kurz- und
> mittelfristigen Zielen den Vorrang zu geben, die man eh unabhängig von
> Electrolysis hätte angehen müssen (kein I/O auf dem Hauptthread,
> Zeichengeschwidigkeit verbessern, SQL Schemata und Queries optimieren, neue
> Cache-Architektur, etc.). Diese Arbeiten sollen im 3. oder 4. Quartal
> abgeschlossen sein, und danach will man sich wieder auf Electrolysis
> besinnen. Keines der genannten Probleme wäre durch Electrolysis gelöst
> worden. Sie haben aber dennoch erheblichen Einfluss auf die Geschwindigkeit
> der Oberfläche und der Aufwand ist geringer und besser planbar, als für
> einen kompletten Umbau der Browser-Architektur.

Seit mind. 2009 wird an Elektrolysis gearbeitet und alleine letztes Jahr 3 mal auf Eis gelegt und jedes mal fängt man fast wieder von vorne an, weil sich in der Zwischenzeit zu viel geändert hat. Alleine wenn man UI in einen eigenen Prozess auslagert, hätte man mit einem Schlag den größten Kritikpunkt des Firefox beseitigt. Gerade wenn man auf eine wirklich extrem lahme Seite trifft, wird der Gesamte Firefox unbenutzbar, da helfen auch die Snappy Projekte nicht, beim Chrome wird nur das jeweilige Tab unbenutzbar und nicht der gesamte Browser.

[Erunno]

klink schrieb:
--------------------------------------------------------------------------------
> Zum einen gibt es Für Linux und Mac Native 64bit Versionen und zum anderen
> ist eine Native 64bit Anwendung sicherer und mit Optimierung kann man auch
> deutliche Performance gewinne machen.

Deutlich? Wo genau? Jetzt bitte wieder keine Allgemeinplätzchen backen. Welche Operationen würden wie genau von 64 Bit profitieren, vor allem im täglichen Browsereinsatz und nicht nur in synthetischen Benchmarks, die teilweise Sonderfälle testen? Auf arewefastyet.com ist die momentane JavaScript-Engine (JM+TI)
in ihrer 64-Bit-Ausführung bei kraken 11%, bei Sunspider 5% und bei v8bench 12 Prozent schneller als ihr 32-Bit-Pendant, vorausgesetzt die Tests werden auf der gleichen Maschine ausgeführt.

> jedes mal fängt man fast wieder von vorne an, weil sich in der Zwischenzeit zu viel > geändert hat.

Wo hast Du denn das her? Neue Features werden weiterhin mit Electrolysis im Hinterkopf konzipiert, so dass man sie in Zukunft mit überschaubaren Aufwand umstellen kann.

> Alleine wenn man UI in einen
> eigenen Prozess auslagert, hätte man mit einem Schlag den größten
> Kritikpunkt des Firefox beseitigt.

Äh, das ist genau der Punkt, warum sich die Electrolysis-Geschichte so lange hinzieht. Firefox und Gecko besitzen nun einmal eine Architektur, die von nur einem Prozess ausgeht. Diese Annahme zieht sich durch den ganzen Code und das zu entflechten, ohne dabei funktionelle und Geschwindigkeitsregressionen zu verursachen, ist alles andere als trivial. Zumal alle Erweiterungen umgeschrieben werden müssten, die in irgendeiner Weise mit dem Seiteninhalt interagieren.

> Gerade wenn man auf eine wirklich extrem
> lahme Seite trifft, wird der Gesamte Firefox unbenutzbar, da helfen auch
> die Snappy Projekte nicht,

Deswegen hat man ja Electrolysis nicht aufgegeben. Alle Verbesserungen auf dem vom Mozilla kontrolliertem Code helfen wenig, wenn eine Seite komplexe und langwierige Berechnungen durchführt und diese den Hauptthread blockieren. Wie gesagt gibt es aber auch noch genug Baustellen, die unabhängig von Electrolysis bearbeitet werden wollen, ebenfalls das Nutzererlebnis negativ beeinträchtigen und noch in diesem Jahr fertig werden können.

> beim Chrome wird nur das jeweilige Tab
> unbenutzbar und nicht der gesamte Browser.

Du hast wohl noch nie probiert, wirklich viele (>10) Tabs auf einmal zu öffnen, die auf halbwegs komplexe Seiten verweisen, oder? Da kommt Chromes so hoch gerühmte Architektur deutlich an ihre Grenzen und der ganze Browser stockt. Woran das liegt (Browser-Prozess mit zu vielen Nachrichten überfordert, zu viele Timer, etc.) ist mir auch nicht ganz klar.

[Thaodan]

Das Problem mit der x86_64 Version besteht nur unter Windows.
Unter Linux wird generel seit Jahren nur die 64bit Version verwendet.