Nightly 64.0a1 (32-bit) lahmt beim scrollen

regie510

Hallöchen,

mir ist zufällig aufgefallen, dass die Scroll-Performance der neuen Nightly 64.0a1 vom 05.09. (32-bit) schlechter ist als bei der 63er-Nightly im direkten Vergleich. Das Scrollen gerade durch längere Seiten ist nicht mehr schön schnell und direkt mit dem Mausrad, es wirkt leicht verzögert, etwas hinterherhinkend, nicht mehr "Quantum like" :wink: Okay, das ist die erste 64er-Alpha, aber hat sich da etwas gravierendes in dieser Richtung "unter der Haube" geändert? Auch die aktuelle 62er Release und Beta scrollen wie gewohnt schön fix.

Getestet im abgesicherten Modus und auch mit frischem Profil, bleibt gleich. Mein Rechner ist weißgott nicht mehr der Jüngste, ich bekomme auch keine aktuellen Grafiktreiber mehr. Aber wie oben erwähnt, die älteren Füchse rennen sehr gut. Ich weiß natürlich nicht, ob das mit aktueller Hardware überhaupt auffällt.

Gruß, Nobby

madperson

hallo, bei solchen problemen die erst seit kurzem auftreten und sich auch in einem neuen profil leicht reproduzieren lassen, wäre die ideale vorgehensweise mit dem tool von https://mozilla.github.io/mozregression/ herauszufinden, durch welche änderung das konkret ausgelöst wurde und dann einen bug report dazu anzulegen. das video auf der seite des mozregression tools sollte eine gute einführung dazu geben, wie man das tool benützen kann, bei unklarheiten kannst du natürlich aber auch hier fragen...
danke!

regie510

Hallöchen madperson,

mozregression habe ich im Einsatz. Damit habe ich herausgefunden, dass seit der ersten Version der Nightly 64.0a1 (32-bit) dieses Scrollproblem bei mir auftaucht. Die letzte 63er-Nightly war in dieser Richtung noch okay. Das Tool ist super, um Fehler zu finden.

Gruß, Nobby

madperson

nachdem das tool mit den nightly versionen durch ist, sollte es auf mozilla-inbound/autoland builds wechseln, wo die einzelnen patches die in nightly aufgenommen werden landen. am ende steht dann in der regel eine einzige änderung/ein einzelner bug, der das problem ausgelöst hat & mit dieser information findet man häufig schnell einen verantwortlichen, der das problem auch wieder gerade biegen kann...

regie510

Zitat von madperson

nachdem das tool mit den nightly versionen durch ist, sollte es auf mozilla-inbound/autoland builds wechseln, wo die einzelnen patches die in nightly aufgenommen werden landen. am ende steht dann in der regel eine einzige änderung/ein einzelner bug, der das problem ausgelöst hat & mit dieser information findet man häufig schnell einen verantwortlichen, der das problem auch wieder gerade biegen kann...

Der Fehler liegt zwischen diesen beiden Versionen - die letzte gute:

app_name: firefox
build_date: 2018-09-03
build_file: C:\Users\Admin\.mozilla\mozregression\persist\2018-09-03--mozilla-central--firefox-63.0a1.en-US.win32.zip
build_type: nightly
build_url: https://archive.mozilla.org/pub/firefox/ni…en-US.win32.zip
changeset: d14aaf65a80b3baddb193fa6707e4515e4a44609
pushlog_url: https://hg.mozilla.org/mozilla-centra…d49c7a1ba28166c
repo_name: mozilla-central
repo_url: https://hg.mozilla.org/mozilla-central

Die erste schlechte:

app_name: firefox
build_date: 2018-09-04
build_file: C:\Users\Admin\.mozilla\mozregression\persist\2018-09-04--mozilla-central--firefox-64.0a1.en-US.win32.zip
build_type: nightly
build_url: https://archive.mozilla.org/pub/firefox/ni…en-US.win32.zip
changeset: bade35bc346f3bc1f5e8b59d3d49c7a1ba28166c
pushlog_url: https://hg.mozilla.org/mozilla-centra…d49c7a1ba28166c
repo_name: mozilla-central
repo_url: https://hg.mozilla.org/mozilla-central

Gruß, Nobby

madperson

leider gibt es zwischen beiden versionen gut 100 änderungen - springt mozregression danach nicht automatisch zu inbound oder autoland builds weiter?

regie510

Ich habe nun eine viel genauere Auswahl, die erste 64.0a vom 04.09. 23:52 Uhr war noch in Ordnung:

app_name: firefox
build_date: 2018-09-04
build_file: C:\Users\Admin\.mozilla\mozregression\persist\2018-09-04--mozilla-central--firefox-64.0a1.en-US.win32.zip
build_type: nightly
build_url: https://archive.mozilla.org/pub/firefox/ni…en-US.win32.zip
changeset: bade35bc346f3bc1f5e8b59d3d49c7a1ba28166c
pushlog_url: https://hg.mozilla.org/mozilla-centra…064bbdc130a0040
repo_name: mozilla-central
repo_url: https://hg.mozilla.org/mozilla-central

Dann kam am selben Tag um 23.59 Uhr die erste schlechte Version:

app_name: firefox
build_date: 2018-09-04 23:59:31.358000
build_file: C:\Users\Admin\.mozilla\mozregression\persist\c3734e0f634e--mozilla-central--target.zip
build_type: inbound
build_url: https://queue.taskcluster.net/v1/task/JKcEPm…ld%2Ftarget.zip
changeset: c3734e0f634e10ad994112e49d1849817c1688ff
pushlog_url: https://hg.mozilla.org/mozilla-centra…d1849817c1688ff
repo_name: mozilla-central
repo_url: https://hg.mozilla.org/mozilla-central
task_id: JKcEPm9vSIOQgsko-P7K9g

Vielleicht ist das hilfreicher.

Gruß, Nobby

madperson

macht es einen unterschied wenn du die einstellung layout.display-list.retain.chrome in about:config auf false setzt und einmal neu startest?

regie510

Zitat von madperson

macht es einen unterschied wenn du die einstellung layout.display-list.retain.chrome in about:config auf false setzt und einmal neu startest?

Super, besten Dank - und ob das einen Unterschied macht. So rennt der Fuchs wieder wie gewohnt :klasse:

Gruß, Nobby

Boersenfeger

... was besagt denn der umgelegte Schalter?

regie510

Zitat von Boersenfeger

... was besagt denn der umgelegte Schalter?

Ich konnte dazu nur folgendes finden, habe aber davon nicht den blassesten Schimmer, wenn's soweit ins Getriebe rein geht:

https://hg.mozilla.org/mozilla-central/rev/716d49302a28

Nur, dass das Aktivieren wohl irgendwie Performance warum auch immer kostet :wink:

Sören Hentzschel

Ich zitiere aus meinem Artikel zu Firefox 61:

Zitat

Retained Display Lists
Das Display List Building bezeichnet den Prozess, in welchem die Elemente wie Ränder, Hintergründe usw. gesammelt werden, welche auf dem Bildschirm angezeigt werden sollen und dann gemäß der CSS Painting-Regeln sortiert werden. Bislang musste die sogenannte Display List jedes Mal neu berechnet werden, wenn eine Änderung der Anzeige erfolgte. Dieser Vorgang kann langsam sein, insbesondere mit den immer komplexer werdenden Webseiten sowie den immer größeren Bildschirmen, welche von den Nutzern eingesetzt werden. Retained Display Lists ermöglichen es, dass nur die Teile neu berechnet werden müssen, die sich auch tatsächlich geändert haben. In einem Test konnte die Häufigkeit langsamer Ausführungen um 30 Prozent reduziert werden.

Das erklärt Retained Display Lists. Diese sind bislang nur für Webseiten-Content aktiviert. Der Schalter aktiviert respektive deaktiviert Retained Display Lists für das chrome, d.h. die Firefox-Oberfläche. Die Firefox-Oberfläche ist ja auch mit CSS gestaltet. (Nachtrag: Genauer wäre vielleicht, es war bisher für Content-Prozesse aktiviert und damit auch für den Parent-/Chrome-Prozess).

regie510

Danke für die Erklärung, Sören. So hab ich es in etwa kapiert, was damit gemeint ist. Spasshalber schaute ich mal in die Firefox-Versionen 62 Release und Beta. Dort ist dieser Schalter defaultmäßig deaktiviert.

Gruß, Nobby

Sören Hentzschel

Richtig, das ist erst für Firefox 64 geplant.

regie510

Zitat von Sören Hentzschel

Richtig, das ist erst für Firefox 64 geplant.

Ich schätze mal, dass der Grafiktreiber für das Rendern an sich zuständig ist. Wenn ich den Schalter aktiviere, scrollen die Webseiten deutlich gebremster. Da mein Laptop schon betagter ist, bekomme ich von Intel kein Update mehr.

Gruß, Nobby

Sören Hentzschel

Retained Display Lists sorgen für keine zusätzliche Einbindung der Grafikkarte. Das sorgt vereinfacht gesagt nur dafür, dass weniger neu berechnet werden muss. Es führt also etwas mehr Komplexität ein, weil Firefox erkennen muss, was sich verändert hat, statt einfach immer alles neu zu berechnen, am Ende sollte Firefox in den meisten Fällen aber weniger langsame Operationen ausführen müssen. Wie gesagt, für Content-Prozesse und damit de facto Webseiten ist das eh schon seit Firefox 61 aktiviert. Der von dir deaktivierte Schalter ändert daran auch nichts, damit ist es für Content-Prozesse immer noch aktiviert. Wenn du mit der Darstellung von Webseiten und der Webseiten-Performance keine Probleme hast, wird ein Grafikkarten-Treiber nicht notwendig sein.

Ab Firefox 64 soll es zusätzlich für den Chrome-Prozess, also im Endeffekt für die Firefox-Oberfläche, aktiviert werden. Der genannte Schalter hat nur darauf Auswirkungen. Da das ganz frisch in einer Nightly-Version aktiviert worden ist, ist es natürlich möglich, dass es da noch Probleme gibt, die hoffentlich aber noch rechzeitig gelöst werden. Da würde ich mir wenig Sorgen machen, gemeldet wurde dein Scroll-Problem ja schon.

Boersenfeger

Auch von mir Danke....

regie510

Bestens, lieber Sören - ich möchte mich auch ganz herzlich für Deine Erklärung und Dein großes Engagement hier bedanken :klasse:

Gruß, Nobby