6 Reaktionen

Firefox Nightly: Mozilla aktiviert WebRender für erste Nutzer

Geschätzte Lesedauer:

Der aus dem Servo-Projekt stammende WebRender soll die Grafikkarte stärker als bisher einbeziehen und so für eine deutlich verbesserte Firefox-Performance sorgen. Mozilla hat bei der Implementierung von WebRender einen wichtigen Meilenstein erreicht und WebRender nun für erste Nutzer der Nightly-Version von Firefox aktiviert.

WebRender stammt wie die mit Firefox 57 eingeführte CSS-Engine Stylo ebenfalls aus Mozillas Next-Generation-Engine Servo und ist in der Programmiersprache Rust geschrieben. Es handelt sich bei WebRender um einen Renderer für Webseiten-Inhalte, welcher unter stärkerer Einbeziehung der Grafikkarte als bisher im Grunde wie eine Spiele-Engine arbeitet, aber für das Rendering von Web-Content optimiert ist und dadurch große Performance-Vorteile liefern soll.

Bei der Entwicklung von WebRender hat Mozilla nun einen wichtigen Meilenstein erreicht: Per sogenannter Shield-Studie hat Mozilla WebRender für einen Teil der Firefox-Nutzer aktiviert, um entsprechende Messwerte zu sammeln, die Mozilla zeigen, wo man steht. Qualifiziert sind ausschließlich Nutzer von Firefox Nightly 63 auf einem Desktop-Computer mit Windows 10 und einer Grafikkarte von Nvidia.

Desktop-Computer mit Windows 10 und einer Grafikkarte von Nvidia machen ca. vier Prozent der Gesamt-Population aller Firefox-Nutzer aus. Dabei handelt es sich um exakt die Zielgruppe, für welche Mozilla eine standardmäßige Aktivierung von WebRender in einer Beta-Version von Firefox 64 anpeilt.

Unter den Nutzern, welche die Kriterien erfüllen, erfolgt im Rahmen dieser Studie eine Aufteilung von 50 Prozent mit aktiviertem WebRender zu 50 Prozent Kontrollgruppe ohne WebRender. Die Dauer der Studie beträgt zwei Wochen, dann wird Mozilla die Daten auswerten und die nächsten Schritte planen.

Wichtig: Performance-Wunder sind in dieser Phase der Webrender-Entwicklung nicht zu erwarten. In erster Linie geht es um Korrektheit bei der Darstellung von Webseiten und um Stabilität. Ein positiver Ausgang der aktuellen Studie besteht für Mozilla dann, wenn mit WebRender diverse Metriken um nicht mehr als fünf bis zehn Prozent schlechter als ohne WebRender sind. Seine großen Vorteile wird WebRender erst in den kommenden Monaten ausspielen können.

Dieser Artikel wurde von Sören Hentzschel verfasst.

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, mozilla.de, firefoxosdevices.org sowie sozone.de.

5 Kommentare - bis jetzt!

Eigenen Kommentar verfassen
  1. Kilian
    schrieb am :

    Spannend! 🙂

  2. Marcel
    schrieb am :

    Ich bin gespannt :)Weißt du zufällig welche Schnittstelle von WebRenderer benutzt wird und in welcher Version? DirectX, OpenGL oder Vulkan?

  3. Sören Hentzschel Verfasser des Artikels
    schrieb am :

    Derzeit wird wohl OpenGL genutzt, aber mehr kann ich dazu nicht sagen.

  4. blub
    schrieb am :

    Laut dem was ich zuletzt gelesen hatte nutzt WebRender unter Windows D3D11 über Angle.

    Place of D3D11 in the new low-level world:

    If gfx-hal wants to be the basis of WebRender, it can't be a regression for those users of Windows 7 platforms. Currently, WebRender is using D3D11 on Windows through Angle.

    In light of this fact, I believe we should bump/revive the priority of getting D3D11 backend ported over to HAL. Hopefully, most of the code is already there, and we don't need any HAL API changes.

    The consensus of this group is that GL is not important for now, it is a secondary goal that shouldn't affect the trade-off and design decisions we make to reach D3D12 and Metal.

    Der eigentliche Code fürs Backend ist wohl auch sehr übersichtlich:

    Core tile rendering loop is ~3 pages of code. Rendering cache is a few more pages. But about 400-500 lines of code. There's a bunch of setup, but the core of the render loop is small and should be adaptable.

    vlad: How easy is it to add DX11/12 backend?
    gw: It was designed to be easily replaced. 90% of the opengl code is on 1 file, 10% in the other. Apart from the boilerplate of compiling shaders, render targets, FBOs, etc. the core loop is only ~500 lines of code.
    pcwalton: Writing the shaders will be the tricky part. They're basically just an unrolled loop.
    gw: About 15 shaders. 8 for blending; 7 for render target stuff. They're fast enough, but not fully optimized.

     

    Aus diesem Issue schließe ich, dass man die einzelnen Backends langfristig mit gfx-rs erschließen möchte: https://github.com/servo/webrender/issues/407
    Da steht auch einiges über Abstraktion vs native APIs.

    Das bringt auch eine Vulkan nahe API mit:

    gfx-rs is a graphics abstraction library in Rust. It consists of the following layers/components:
    gfx-hal: hardware abstraction layer – a Vulkan-ic mostly unsafe API translating to native graphics backends.
    gfx-backend-*: graphics backends for various platforms, include the windowing logic.

    https://github.com/gfx-rs/gfx

    Ob das noch aktuell ist, weiß ich aber nicht.

     

  5. Sören Hentzschel Verfasser des Artikels
    schrieb am :

    Ich hatte nur über OpenGL gelesen, aber ich gehe mal davon aus, dass dein Wissen diesbezüglich zuverlässiger ist beziehungsweise es so ist, wie deine Quelle es schreibt. WebRender ist ja praktisch dein Thema. 😉

Und jetzt du! Deine Meinung?

Erforderliche Felder sind mit einem Asterisk (*) gekennzeichnet. Die E-Mail-Adresse wird nicht veröffentlicht.
  1. Nach Absenden des Kommentar-Formulars erfolgt eine Verarbeitung der von Ihnen eingegebenen personenbezogenen Daten durch den datenschutzrechtlich Verantwortlichen zum Zweck der Bearbeitung Ihrer Anfrage auf Grundlage Ihrer durch das Absenden des Formulars erteilten Einwilligung.
    Weitere Informationen