Beiträge von RedSign

Ich bin gerade daran gescheitert unter Android in Nightly das Zertifikat von Adguard (globaler Werbeblocker) zu installieren. Das ist notwendig, damit auch HTTPS-Seiten gefiltert werden können. Es gibt dafür eine eigene Funktion in der Adguard-App, da Fx nicht den Zertifikatsspeicher von Android, sondern seinen eigenen verwendet. Sobald ich Fx stable als Standardbrowser nutze und dann in Adguard die Funktion zum Importieren der CRT-Datei aufrufe, öffnet Fx das Zertifikat und wirft die Meldung zum Annehmen desselben auf. In Nightly wird zwar die Datei geladen, aber der Dialog fehlt und der Import ist dort daher nicht möglich. Irgendwelche Ideen?

Mein Senf zum Amüsantem (und das ist es wirklich): Ich nutze zurzeit Chrome Canary als Browser im Alltag und habe mal heute Abend das Flag gesetzt nachdem ich gestern vom Redesign las. Meine Fresse, ich war ja schon kein Australis-Fan, aber die Implementaion toppt das mal um Längen. Nicht schön. Aber es ist nur hinter einem Flag und nur in der Canary-Version verfügbar, insofern sollte man das nicht voreilig kritisieren. Wer weiß schon, wie das am Ende wirklich aussehen wird.

Und ja diese ganze Wer-kopiert-wen-Debatte war und ist in der Software-Welt schon immer müßig und irgendwie sinnlos, finde ich.

Chrome Canary unterstützt seit einigen Tagen Direct Manipulate für Laptops mit Windows 10 und einem Precision Touchpad, wie hier in Aktion zu sehen ist. In Kombination mit Chromes guter grafischer Performance fühlt sich das Scrollen so unter Windows 10 meist wie unter nativen UWP-Apps an und lässt andere Browser (außer Edge) in der Hinsicht archaisch wirken. Auch Pinch-to-Zoom und die Zwei-Finger-Gesten zum Vor- und Zurückspringen funktionieren jetzt auf dem Touchpad. Noch ein Grund mehr, Chrome Canary wie in den letzten Monaten auch weiterhin zu nutzen. Würde ich mir für Fx auch wünschen, vor allem in Kombination mit WebRender. Vielleicht Wunschdenken.

Ich hatte das Problem auch noch mit dem heutigen Update. Das Ganze wird unter Bug 1430535 behandelt.

Zitat von Lurtz

Wer gerne mit WebRender rumspielt, es gibt ab dem heutigen Build eine Flag die alle nötigen Flags selbständig aktiviert:
gfx.webrender.all turns on all preferences that are needed for webrender.

Das ist ein toller Hinweis, danke! Ich teste WebRender hin und wieder aus und es ist immer ein wenig fummelig die drei notwendigen Schalter zu setzen und anschließend wieder zurückzustellen. WebRender wird auf meiner Maschine mit Intel HD 520 immer besser. Bisher ist die Leistung ohne WebRender aber noch etwas besser. Grafikfehler treten von Nightly zu Nightly und Anwendungszenario immer mal wieder auf, halten sich aber in Grenzen.

Mir ist bezüglich des von mir vor Kurzem aufgebrachten Themas der Scrolling-Performanz von Fx etwas aufgefallen, das ich bisher nicht bedacht habe.

Ich habe die Website theoutline.com als ein Beispiel für eine grafisch aufwendigere Website genannt, die bei mir unter Fx beim Scrollen leicht hakelig gegenüber Edge erscheint. Die Rückmeldungen waren durchgehend, dass man das Problem nicht nachvollziehen könne und das Ganze auf dem jeweiligen System mit gefühlt konstanten 60 FPS vonstatten geht.

Ich glaube der Grund dieser unterschiedlichen Wahrnehmungen ergibt sich aus zwei Punkten:

• Ich bin auf einem Surface Book mit vergleichsweise begrenzter Grafikleistung unterwegs (Intel HD 520) und
• die Maschine nutzt eine Auflösung von 3000 x 2000 Pixeln und natürlich nutze ich Fx im maximierten Fenster.

Lezteres wird in Kombination mit der vorhandenen Grafikleistung des Systems der Hauptgrund sein. Wenn ich die Auflösung nur auf Full HD (1920 x 1080 Pixel) senke, fliegt Fx beim Scrollen unter theoutline.com nur so durch die Seite wie geschnitten Brot. Gleiches Ergebnis, wenn ich die Breite des Fx-Fensters bei der nativen Auflösung auf rund 2/3 des verfügbaren Raumes stelle.

Noch etwas ist mir vor einigen Tagen bereits aufgefallen: Ich habe mich bis dahin gewundert, warum sich Fx mal flotter und mal träger anfühlt, bis ich bemerkt habe, dass Fx immer flotter erscheint, wenn das Surface Book am Ladekabel hängt. Ausgehend davon habe ich beim Akkubetrieb mit den verschiedenen Energie-Modi unter Windows 10 herumprobiert und konnte feststellen, dass der Energiestatus "bessere Leistung" in der Tat das gleiche Verhalten erzeugt wie am Ladekabel. Ich habe viel rumprobiert, weil ich mir teils selbst nicht sicher war, ob das nur ein Gefühl oder eine Tatsache ist, aber ich bin immer wieder zu dem Schluss gekommen, dass der Energiemodus Auswirkungen hat. Eine Suche bei Bugzilla ergab zumindest einen http://Bug-Eintrag, der dieses Verhalten im Zusammenhang mit Webrender und dem Energiestatus "Stromsparmodus" beschreibt.

So oder so bleibt unterm Strich, dass Fx hier sehr deutliche Fortschritte gemacht hat und sich die meisten Websites absolut gut anfühlen.

Jo, bist mir gerade um eine Minute zuvorgekommen, funktioniert in der Tat wieder alles normal mit Build 17063 von Windows 10 und Firefox. Klasse Arbeit mal wieder von Mozilla. :klasse:

Das dachte ich erst, zumal der Fix bei Fx recht einfach umzusetzen scheint. Aber so wie sich der Entwickler auf Reddit äußert scheint ein Fix von MS' Seite zu kommen.

Edit: Es gibt jetzt auch von Mozillas Seite einen passenden Eintrag bei Bugzilla. Sieht bisher so aus als gäbe es einen schnellen Fix.

Microsoft hat mittlerweile im Feedbackhub ein Statement hinterlassen und beschreibt darin, dass es eine Änderung bei diversen APIs zur Regelung der Lautstärke gegeben hat, die mit einigen Drittanbieter-Anwendungen kollidiert. Komplettes Statement, siehe unten. Unklar ist, ob MS hier Anpassungen vornimmt oder dies von den Drittanbietern erwartet.
Der MS-Entwickler hat sich auch auf Reddit geäußert und man arbeitet von MS Seite an einem Fix, der vielleicht im nächsten Build kommt, möglicherweise aber auch erst in den Builds danach.

Zitat von Matthew v - Microsoft-Entwickler

Windows has several audio volume APIs - IAudioEndpointVolume, IChannelAudioVolume, ISimpleAudioVolume, and IAudioEndpointVolume. These APIs can be used to change the volume and/or mute state of the stream, app, or audio device.

In build 17063 a change was made to these APIs to have them return S_FALSE (1) if the requested change was a no-op.

This broke apps (like Firefox) which request changes (that may be no-ops) and then explicitly check the return value against S_OK (0).

Zitat von AngelOfDarkness

Bei reddit schreibst du (und andere) aber was anderes. Demnach habt ihr auch bei Edge teilweise Probleme. Und wie bei einer Insider Build, in diesem doch recht frühen Stadium, nicht anders zu erwarten gibt es da auch noch jede Menge Bugs und Probleme. Einige bereits bekannte : https://www.deskmodder.de/blog/2017/12/1…reit-changelog/
Ansonsten als Insider immer fleissig vom Feedback Hub Gebrauch machen.

Ich hatte initial auch Probleme mit Edge, die sich aber schnell von selbst erledigt haben, denn dort funktioniert nun alles mit Ton wie gewünscht. Aber Fx macht offenbar bei allen Problemen. Natürlich ist das Insider Build in irgendeiner Weise Ursache und natürlich habe ich entsprechendes Feedback im Feedback Hub zu diesem Thema auch schon vor dem Posten hier hochgewertet, aber es hätte ja sein können, dass es hier noch weitere Infos gibt, die das Problem beheben oder zumindest helfen, es einzugrenzen. Sören hatte ja zumindest schon einmal eine Idee. Aber Danke für die Hinweise. :klasse:

Mit dem heutigen Windows Insider Build 17063 habe ich keinen Sound mehr in Fx. Wenn ich mich richtig erinnere, nutzt Fx zum dekodieren von Video und Audio die in Windows eingebauten Codecs, richtig? Irgendwelche Ideen von euerer Seite?

Ich habe sonst systemweit keine Soundprobleme, auch nicht in anderen Browsern wie Edge und Chrome. Aber unter Fx kein Ton unter Youtube, Vimeo und bei der Startseite der Soundcloud geht er sogar alle Titel schnell nacheinander durch und quittiert sie mit der Meldung, dass die Wiedergabe des jeweiligen Titels zurzeit nicht möglich ist.

Edit: Zumindest zwei andere Tester haben sich meiner Problembeschreibung auf Reddit angeschlossen, es scheint also zumindest mit dem neuen Build zu tun zu haben.

Interessant, dass WebRender derart abhängig vom Grafiktreiber ist. Das erklärt vielleicht auch, dass ich mit der aktuellen Implementation hier auf meinem Surface Book bei aktiviertem WebRender durchweg eine etwas schlechtere Performance mit der integrierten Grafik Intel HD 520 habe. Aber dort ist es immerhin nutzbar. Starte ich Fx dagegen mit aktiviertem WebRender unter Verwendung der dGPU (Nvidia) des Surface Book, ist nicht nur die Performance deutlich schlechter, es treten auch diverse Grafikfehler in der Oberfläche von Fx auf, so dass es nicht wirklich nutzbar ist.

Zitat von Lurtz

The Outline läuft butterweich in meinem Firefox. Sicher dass Hardwarebeschleunigung und APZ bei dir aktiv sind?

Laut about:support ist beides aktiv:

Compositing	Direct3D 11 (Advanced Layers)
Asynchrones Wischen und Zoomen	Mausrad-Eingabe aktiviert; Berührungs-Eingabe aktiviert; Ziehen der Bildlaufleiste aktiviert; Tastatur aktiviert; automatischer Bildlauf aktiviert

Zitat von Lurtz

Es kommt oft auch auf die GPU an. In manchen Szenarien performet meine Intel HD 520 wesentlich besser als meine R9 390, obwohl letztere auf dem Papier deutlich mehr Leistung hat.

Das ist sehr interessant, weil ich ein Surface Book mit einer zusätzlichen dedizierten Nvidia-GPU habe und daher auch schon probiert habe, wie sich Fx verhält, sobald ich ihn mit der dGPU statt dem Intel-HD-520-Chip im Bildschirmteil verwende. Erstaunlicherweise waren alle normalen Aktionen auf Websites z. B. das Scrollen spürbar schlechter, dafür aber 3D-Anwendungen per WebGL deutlich performanter. Ich dachte das sei eine besondere Anomalie meines Systems.

Zitat von Lurtz

Ganz so einfach ist es sicher nicht:
https://blogs.windows.com/msedgedev/2017…ing-on-the-web/
https://blogs.windows.com/msedgedev/2017…dent-rendering/

Du hast natürlich recht, dass MS in diesem Bereich seit Windows 8 weitere Verbesserungen vorgenommen hat, das war mir schon bewusst. Ich habe mich etwas unglücklich ausgedrückt ("1:1 übernommen"). Ich wollte damit sagen, dass dieses auffällig glatte Scrollen mit der ersten Version des IE, die auch komplett auf Touchbedienung ausgelegt war, erstmals eingeführt wurde und das war der IE 11. Plötzlich verhielt sich ein Desktopbrowser wie ein Touch-Browser auf Tablets und Smartphones mit butterweichem Scrollen und Zoomen. Edge hat dies übernommen und darauf aufgebaut. Das war also eher ein fließender Übergang als ein harter Schnitt mit der Einführung von Edge:

Zitat von blogs.windows.com: Making the web smoother with independent rendering

This technique was pioneered in Internet Explorer 11, and is key to providing a fluid experience.

Generell zum Thema:

Einige berichten über das Verhalten unter macOS. Gut möglich, dass das einen Unterschied macht, denn das Scrollen ist unter macOS schon immer gut gewesen, gerade mit den Touchpads von Apple. Ich nutze Windows 10 v. 1709.

Möglicherweise spielt auch die Hardware eine Rolle. Auf einem Desktopsystem mag das anders aussehen, aber ich bin privat ausschließlich mit meinem Surface Book unterwegs und beruflich auf einem Thin-Client, bei dem sich ohnehin jede Bedienung wie durch Watte anfühlt.

Möglicherweise bin ich bei diesem Punkt auch einfach empfindlicher bzw. anspruchsvoller. Aber spätestens bei der Nutzung des Browsers per Touch sind die Unterschiede spürbar, weil der Inhalt beim Scrollen nicht so schön am Finger "klebt" wie unter Edge. Ich vermute aber, dass hier niemand seinen Desktop-Fx mit Touch verwendet. Ich tue dies schon ab und an.

Ich nutze keine Maus, sondern ausschließlich das Touchpad des Surface Book. Bei Mausnutzung sind die Unterschiede zugegeben weniger spürbar.

Ich habe Smooth Scrolling in den Einstellungen deaktiviert, weil das m. E. gar nicht geht, wenn es aktiviert ist. Das führt nämlich zu einer Verzögerung mit der das Scrollen einsetzt, die ich gar nicht mag. Das soll sofort reagieren und am Finger kleben. Ich beziehe mich also auf das nackte Scrollen ohne dieses Verzögern durch Smooth Scrolling. An den Rucklern ändert aber Smooth Scrolling auch nichts, nur dass halt noch diese Verzögerung hinzukommt bevor das Scrollen einsetzt.

Vielleicht mache ich demnächst mal ein Video mit einem Vergleich. Mal sehen. Aber besten Dank für die interessanten Rückmeldungen von euch.

Zitat von Lurtz

Auch das APZ ähnliche Scrollen wurde erst vor kurzem eingeführt.
Es ist nicht alles neu was EdgeHTML heißt

Da muss ich aus Erfahrung widersprechen. Auch der IE unter Windows 8, sowohl in der Metro- als auch Desktopvariante bot schon dieses Scrollverhalten. Edge hat dies nur 1:1 übernommen.

Ich bin gerade über ein gute Beispielseite gestolpert für die gestern von mir beschriebenen Unterschiede bei der Grafikleistung zwischen Edge, Fx und Chrome. Die Startseite von The Outline verhält sich unter den verschiedenen Browser auf meinem Surface Book wie folgt:

Firefox: Das Scrollen ist deutlich ruckelig.

Chrome: Das Scrollen ist weicher als bei Fx, dafür aber spürbar verzögert. Wenn ich etwas hin- und herscrolle und die Finger vom Touchpad nehme, scrollt die Seite aufgrund dieser Verzögerung noch rund eine halbe bis eine Sekunde weiter hin und her.

Edge: Bis auf vereinzeltes Mikro-Stottern scrollt sich die Seite glatt und weich wie gewohnt.

Zugegeben: Chrome verhält sich erstaunlicherweise auf dieser Seite deutlich eingeschränkter als Fx, was meinem generellen Eindruck zwischen den beiden Browsern widerspricht, aber Edge ist auch hier für mich deutlich am angenehmsten.

Ich weiß, dass ich bezogen auf diesen Aspekt wohl ein besonders Empfinden habe und sehr viel Wert darauf lege. Aber die Interaktion mit Websites zu ermöglichen ist Hauptaufgabe eines Browsers und wie flüssig es sich scrollen lässt und Animationen ablaufen macht einen großen Teil davon aus, gerade im modernen Web.

Irgendwas scheint Microsoft in diesem Bereich anders zu machen und mich würde wirklich interessieren, wie sich diese Unterschiede auf der technischen Ebene ergeben. Weiß da jemand mehr?

Ich bin übrigens sehr erfreut, dass sich das Forum hier offenbar in den vergangenen Jahren gewandelt hat. Ich kann mich noch an Zeiten erinnern, wo solche Beiträge von mir einen Shitstorm mit zahlreichen Anfeindungen nach sich gezogen hätte. Stattdessen wird sich sachlich mit dem Thema auseinandergesetzt. Ein sehr feiner Zug von euch. :klasse:

Sosehr mir Fx ab Version 57 mit seiner tollen, neuen Oberfläche, der soliden Leistung unter der Haube und der guten Anpassbarkeit durch Erweiterungen und den vielen Einstellungsmöglichkeiten (about:config) auch gefällt, bin ich doch wieder zurück zu Edge als meinen Hauptbrowser.

Ich habe einfach die unglaublich gute Grafikleistung von Edge vermisst. Fx ist da nahe dran, aber es gibt immer wieder Situationen, in denen Seiten stotternd oder verzögernd scrollen, beispielsweise auf Youtube bei einem Video mit vielen Kommentaren darunter oder auch auf Text- und CSS-intensiven Seiten wie Beiträgen auf reddit mit vielen eingeblendeten und verschachtelten Kommentaren. Bei einem Quervergleich mit Edge und Chrome stellt sich dann immer heraus, dass Chrome es etwas besser hinbekommt und Edge das ganze perfekt mit 60 fps umsetzt.

Ich habe mir den interessanten Artikel zu WebRender von Lin Clark durchgelesen und dort schreibt sie sehr zutreffend und mir aus der Seele sprechend: "If you want things like scrolling or animation to look smooth, they need to be going at 60 frames per second."

Den im Artikel erwähnten Test, dessen Animationen mit WebRender mit sauberen 60 fps ausgeführt werden, laufen unter Edge bereits jetzt mit 60 fps.

Ich warte gerne auf WebRender, weil ich wirklich Interesse daran habe, wieder Fx zu nutzen. Bis dahin nutze ich mit Edge einen Browser, der m. E. schon jetzt das erreicht, was Mozilla mit WebRender erreichen will.

Ich bin ja erst seit einigen Tagen wieder eingestiegen was Fx angeht und habe das bisher auch nicht bereut, da ich ich das Design und die Performance seit v57+ als überzeugend empfinde.

Was mich allerdings irritiert ist dieser Speedometer-Test samt Vergleich mit Chrome. Wenn ich das richtig mitbekommen habe, soll Fx in diesem Test nahe an Chromes Leistung herankommen. Auf meinem System (Surface Book) kann ich das allerdings nur bedingt nachvollziehen: Fx schließt hier mit 33,58 Durchläufen pro Minute ab, während Chrome einen Wert von 50,60 erreicht. Das ist m. E. ein deutlicher Abstand. Ich vergleiche hier übrigens das aktuelle Fx Nightly mit dem aktuellen Release von Chrome. Der aktuelle Canary Build von Chrome liegt allerdings auf dem gleichen Niveau.

Habe ich hier etwas verpasst oder missverstanden?

@Sören
Ja, es ging um das maximierte Fenster, das hätte ich vielleicht erwähnen sollen, da das aus dem Screenshot ja nicht zu erkennen war. Ich persönlich empfand diesen Leerplatz sofort als optisch seltsam und dachte an einen Bug und musste erst überlegen, um in Erwägung zu ziehen, dass das auch einen praktischen Nutzen haben könnte. M. E. reicht es aus, wenn man einfach auf der rechten Seite hinter dem letzten Tab ein wenig Platz lässt. Das sieht weniger seltsam aus und erfüllt den gleichen Zweck. Wie das unter macOS ist, ist mir ehrlich gesagt als Windows-Nutzer ziemlich wumpe, aber ich gebe dir recht, dass das einheitlich sein sollte.

Ah, danke Lurtz. Nach meinem Beitrag wurde mir wieder gewahr, dass ja schon auf der rechten Seite der Tableiste immer ein wenig Platz gelassen wird, um die Titelleiste noch bedienen zu können, wenn sehr viele Tabs auf ihr liegen. Insofern erschien das auf der linken Seite unnötig, so dass ich schon vermutete, dass das nicht so sein soll.

Mit dem heutigen Nightly wird bei mir eine kleine Lücke ganz links in der Tableiste freigelassen. Ist das mit Absicht so, damit man auch bei einer vollen Tableiste immer die Möglichkeit hat, das Fenster mit Tittelleiste verschieben zu können?
[Blockierte Grafik: https://i.imgur.com/kWbE9wr.png]