Auch für Nichtengländer?

Entwicklung Firefox
-
pcinfarkt -
15. August 2009 um 20:46 -
Erledigt
-
-
Zitat von klink
Der Name ist doch schon selbsterklärend!
Diese Art von arroganten Antworten magst du dir bitte sparen.
Erkläre doch einfach warum eine vielfädige Bildaufbereitung schneller ist.
Edit: falschen Autor korrigiert.
-
@.Hermes...du hast falsch zitiert.
-
-
Und auch Metro für die x64 Version wurde eingeschaltet.
-
-
-
:klasse:
-
Zitat von klink
Dadurch werden Bilder schneller dekodiert und werden dementsprechend schneller angezeigt.
Manchmal bin ich wirklich erschrocken, mit welchen Plattitüden die Mitglieder hier abgespeist werden.
-
Dann erkläre es bitte. Solche Aussagen sind keinen Deut besser, wenn dann nichts kommt. Ich kanns nicht erklären, weil mir die Zeit fehlt und ich den Bug nicht näher angesehen habe, das aber ziemlich technisch beschrieben aussieht, entsprechend dankbar wäre auch ich.
Wichtiger finde ich auf jeden Fall, dass Bug #830267 [1] nun gelandet ist, womit sich selbst wieder aktivierende Plugins nach Plugin-Updates hoffentlich der Vergangenheit angehören. Insbesondere für Click-to-Play entscheidend. Auch toll, dass nun Bug #782211 [2] gelandet ist. Dabei handelt es sich um das Notifications API, welche Webseiten Desktop-Benachrichtigungen (nach Erlaubnis durch den Benutzer) ermöglicht. Das Ganze kann unter [3] getestet werden. Wieso die besondere Erwähnung in diesem Thread? Weil das auch für Firefox/Thunderbird selber relevant ist, welche ihre Benachrichtigungen (Abgeschlossener Download, Neue E-Mail, Update ausgeführt) darüber abfeuern. Interessant insbesondere unter Mac OS X, weil hier nun kein Growl mehr benötigt wird (und auch nicht mehr genutzt wird), das heißt die Notwendigkeit eines System-Plugins (welches auch noch Geld kostet) entfällt endlich. \o/ Und Bonus: Das läuft auf jeder Plattform, auf OS X also nicht erst ab Version 10.8 wie die Mitteilungszentrale.
[1] Bug 830267 - Don't store plugin preferences via pluginreg.dat: store them per-mimetype (Flash plugin settings not kept when updating it)(Java plugin reenabled randomly)(All plugins reenabled when switching architectures on mac)
[2] Bug 782211 - Implement notification API spec
[3] HTML5 Notfications - JSbin -
-
Nur da wo viele/große Bilder sind und auch das aufpoppen von Bildern beim scrollen sollte damit der Vergangenheit angehören. Am stärksten dürfte sich das wohl eher eher "schwachen" Computern auswirken.
Edit: auch bekannt unter OMTID (Off-Main-Thread Image Decoding) -
Zitat von MonztA
Heißt das nun, dass Seiten generell schneller laden dürften?
Ja und nein.
Der im Report beschriebene Eingriff gehört zu den komplexeren Änderungen.
Bei rein textlastigen Seiten werden keine Auswirkungen spürbar sein. Jedoch bei Seiten mit Grafiken ist die Ladezeit kürzer, weil jetzt die neue Aufgabenverteilung wirkt.Der gesamte Hintergrund ist das "Warten der Threads". Wenn man die Arbeit der Bildaufbereitung von Threads die auf irgendetwas warten müssen auf Threads delegiert , die sich um nichts anderes kümmern müssen, erfährt man einen Geschwindigkeitsgewinn. Jedoch nur dann, wenn es auch die Ressourcen des PC hergeben.
P.S.
Das Scrollen der Grafiken gehört nicht zur Thematik, weil diese schon dekodiert im Speicher liegen. Da geht es nur noch darum, sie schnell zur Grafikkarte zu schubsen. -
Danke euch für die Erklärung!
-
Es ist wunderschön anzusehen, wieviel Energie Mozilla in die JavaScript-Fähigkeiten von Firefox investiert. Und es unterstreicht für mich, welche wichtige Bedeutung JavaScript hat (*in Richtung NoScript schiel*). OdinMonkey wurde ja ein paar Beiträge vorher erwähnt, hier ist auch schon der Begriff Baseline-Compiler gefallen, womit man in Benchmarks den Chrome schon fast überall erreicht hat (schwarze Linie ansehen [1]), und mit Bug #829602 [2] ist nun ein weiterer ganz großer Schritt gelandet. Es ist nur ein Anfang und es wird noch einige Zeit vergehen, bis alles implementiert ist, was zu diesem Projekt gehört, aber es ist der erste Schritt in Richtung Parallele Verarbeitung von JavaScript. Multithreading für JavaScript, abseits von WebWorkers. Damit kann auch JavaScript mit steigender Anzahl an CPU-Kernen skalieren. Eine klasse Sache, wo wir bereits an dem Punkt angekommen sind, wo acht Kerne in einem Smartphone Realität sind. Firefox ist übrigens der erste Browser, welcher Funktionen zur parallelen JavaScript-Verarbeitung beherrscht.
[1] http://arewefastyet.com/
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=829602 -
Anstatt den Bug 812695 zu fixen, will Mozilla einfach alle betreffenden Grafikkarten auf die blackliste setzen. Unter Win 7 und 8 haben die Radeon HD 2,3, 4 und 7 reihe alle Darstellungsfehler die seit Monaten bekannt sind. Mozilla sollte endlich am Azure arbeiten und die d2d bug fixen und nicht alle Ressourcen in das Drecks Firefox OS stecken!
-
Wow. So viel Quark in einem so kurzen Beitrag.
1. Dir ist klar, dass das mit Firefox OS ganz andere Zuständigkeiten sind und du mit dieser Bemerkung vollkommen Fehl am Platz bist? Und das vor allem nicht jeder deine Meinung teilt und die Bezeichnung "Drecks Firefox OS" definitiv keine Diskussionsgrundlage ist, ja?
2. Dir ist klar, dass Mozilla permanent an Azure arbeitet? Azure ist kein einmal implementiertes und abgeschlossenes Projekt.
3. Dir ist klar, dass in dem von dir verlinkten Report Abhängigkeiten von und mit Microsoft sowie AMD bestehen? In dem von dir verlinkten Bug steht sogar:
ZitatLast from MS on 3/21/13: We were able to get your repro case working on the latest drivers and are still triaging this bug.
Achte auf das Datum, das war gestern. In Anbetracht dieses Tempos ergibt die Entscheidung nämlich durchaus Sinn, die entsprechenden Geräte erst einmal zu blockieren. Mozilla ist durchaus dafür bekannt, Dinge lieber richtig zu lösen, wobei es auch nicht gerade danach aussieht, als hätte man eine kurzfristige Lösung. Dieses Problem bedarf also ganz dringend einer vernünftigen Lösung und solange diese nicht vorhanden ist, muss eben irgendwie reagiert werden. Und das ist eben das Blockieren der entsprechenden Karten. Die Alternative dazu wäre, die Nutzer damit stehen zu lassen.
-
Der größte teil des Grafik teams ist schon länger nur am Firefox OS dran zuletzt haben einige dann am Metro gearbeitet.
Am Azure wird schon seit Monaten nicht mehr gearbeitet und dieser Fehler wird durch Azure verursacht. AMD hat schon vor längerem gesagt, es liegt am Firefox. Das ist auch meine Beobachtung, als ich noch eine Radeon HD 4870 hatte, hatte ich nur im Firefox diese Darstellungsfehler und sonst in keinem anderem Browser oder Programm. Seit längerem habe ich eine Radeon 7870 und auch mit dieser habe ich Darstellungsfehler und auch hier nur Firefox betroffen.Zitata lot of the OMT* is being done on priority for FFOS and Android, and later trickling to desktops. Has the traditional desktpos (win, lin and mac) market become second tier platform for mozilla ?
No, certainly not, although we have a lot of work to do on mobile, so that is a focus for many engineers right now. OMT* is developed for mobile because it is needed most there.
http://featherweightmusings.blogspot.de/2013/02/omtc-questions.html
Viele Projekte wurden zu Gunsten von FFOS and Android eingefroren oder eingestellt. -
Ich find's faszinierend, wie gut du die Mitarbeiter von Mozilla alle kennst und weißt, wer in welchen Projekten involviert ist. Hut ab, so gut bin nicht einmal ich informiert.... Bemerkenswert auch, dass du mit solcher Sicherheit weißt, dass niemand bei Mozilla an Dingen arbeitet, welche mit Azure in Verbindung stehen. Und nicht minder spannend, dass du eine umfassende Analyse des Problems gemacht hast, welche du Mozilla mit Sicherheit auch mitgeteilt hast. Ich habe Grafikkarte XY und Darstellungsfehler nur in Firefox, also ist Firefox das alleinige Problem., das ist ziemlich kurzsichtig von dir gedacht. So einfach ist die Welt nun einmal nicht.
Ich hasse es wirklich, wenn ich mich wiederholen muss. Ich hatte es schon im letzten Beitrag gesagt: Derzeit gibt es offensichtlich keine kurzfristige Lösung, das ist Sachlage. Nicht deine Behauptungen. Ergo zieht man das Blockieren entsprechender Geräte in Betracht, bis man eine vernünftige Lösung hat. Und hier bestehen Abhängigkeiten von und mit Microsoft sowie AMD. Hätte Mozilla das Problem bereits lösen können, hätten sie es mit Sicherheit gelöst. Du beschwerst dich über die Maßnahme. Was wäre denn die Alternative? Die Alternative dazu wäre gar nichts zu machen und die Nutzer weiter das Problem haben zu lassen. Toller Einfall. Noch einmal: Derzeit existiert keine Lösung für das Problem und Mozilla steht in Absprache mit Microsoft, um das Problem zu lösen. Es geht mit dieser Blockierung um eine Maßnahme, bis es eine Lösung gibt. Ich finds ziemlich vermessen von dir, wie du dich hinstellst und ausssagst, dass bezahlte Programmierer von Mozilla mit jahrelanger Berufserfahrung weniger Ahnung von der Sachlage hätten als du. Genau das lese ich aus deinem Beitrag heraus.
Das Zitat sowie die Webseite, von welcher das Zitat stammt, unterstreicht übrigens nicht wirklich deine Behauptung, ganz im Gegenteil. Dieser Beauptung wird bereits im ersten Satz deines Zitates widersprochen. Dass es einen gewissen Fokus auf Mobile gibt, das ist vollkommen klar und verständlich, aber diese vielen Projekte, welche zugunsten von FxOS eingefroren oder eingestellt worden wären, benennst du bitte bei Namen und belegst das. Ansonsten ist es für mich eine wertlose Behauptung. Darauf lege ich großen Wert. Wenn jemand solch große Aussagen trifft, muss er die auch belegen. Vollkommen egal, um welches Thema es geht, das ist eine grundsätzliche Sache.
-
Kann man diese Diskussion abtrennen, da sie nichts mit dem eigentlichen Zweck dieses Threads zu tun hat, danke....
-