WebGL-Performance

WebGL hat einen schlechten Ruf: Viele Entwickler nehmen an, dass WebGL langsam ist und keine komplexen 3D-Grafiken rendern kann. Viele Beispiele beweisen das Gegenteil, dennoch wird dieser Eindruck durch die Erfahrungen der Entwickler immer wieder bestätigt.

Die Hardware, die WebGL-Code ausführt, wird in den Browsern nicht gedrosselt. Warum glauben Entwickler also, dass es unmöglich ist, schnelle 3D-Grafiken im Web darzustellen?

Dieser Artikel führt Dich durch die besten Praktiken zur WebGL-Performance und zeigt Dir, wie auch Du schnelles 3D-Rendering im Web erreichen kannst.

CPU vs GPU 

In einer 3D-Anwendung läuft ein Teil des Codes auf der CPU und ein Teil auf beschleunigter Hardware, der GPU.

WebGL ist so konzipiert, dass es die Nutzung der GPU zur Beschleunigung von Grafik-Anwendungen im Web ermöglicht. WebGL kann daher als Funktionen verstanden werden, die Arbeit an die Grafikhardware senden und das Ergebnis abrufen.

Der Code, der die Arbeit für die GPU erstellt, läuft auf der CPU und wird für WebGL über JavaScript gesteuert.

Browser-Overhead 

Ein Ziel des Browsers ist es, den Nutzer vor potenziell bösartigen Websites zu schützen. Deshalb wird die Sicherheit jeder WebGL-Anfrage, die die Website über JavaScript macht, überprüft. Der Prozess, der den Code der Website ausführt, muss ebenfalls isoliert werden, und alle Anfragen zu und von diesem Prozess müssen in ein sendbares Format umgewandelt werden, was als “Marshalling” bezeichnet wird.

Sowohl das Marshalling als auch die Überprüfung der WebGL-Anfragen der Website verursachen Arbeiten, die mit einem Leistungskosten verbunden sind, verglichen mit denselben Anfragen in einer nativen Umgebung.

WebGL-Anfragen vermeiden 

Um eine gute WebGL-Performance zu erreichen, sollten wir daher Anfragen vermeiden, die hohe Overheadkosten verursachen. Du wirst leicht herausfinden, welche Anfragen besonders teuer sind, indem Du Deine WebGL-Anwendung profilierst.

Folgende Anfragen sind unerwartet teuer:

• getError()
• getParameter()
• getBufferParameter()

Eine hervorragende Möglichkeit, diese Anfragen zu vermeiden, ist das WebGL-Zustandstracking und die Reduzierung der Fehlerüberprüfung in Produktions-Builds Deiner WebGL-Anwendung.

Draw Calls vermeiden 

Das Geheimnis für exzellente WebGL-Performance besteht darin, so wenige Draw Calls wie möglich zu haben. Ein Draw Call ist jede Funktion, die eine der folgenden WebGL-Funktionen verwendet:

• drawArrays()
• drawElements()
• drawArraysInstanced()
• drawElementsInstanced()
• drawBuffers()
• drawRangeElements()

Es gibt viele Möglichkeiten, dies zu erreichen, z. B. durch die Nutzung eines Funktionsaufrufs, der viele Objekte zeichnet, anstatt eine Funktion mehrmals aufzurufen, um dieselben Objekte zu zeichnen. Du kannst Instancing verwenden, um eine große Anzahl des gleichen Meshs zu rendern, oder WEBGL_multi_draw nutzen, um viele verschiedene Objekte mit dem gleichen Shader zu rendern.

3D-Engines bieten oft eine Funktion namens “Batching”, die viele Aufrufe zu einem einzigen WebGL-Aufruf zusammenführt. Wonderland Engine treibt dies auf die Spitze, indem Szenen mit zehntausenden dynamischen Objekten automatisch in weniger als zehn Draw Calls gerendert werden.

Die WebGL-Performance auf Mobilgeräten wird besonders durch Draw Calls beeinflusst.

Draw Calls vermeiden (Mobil) 

Wir erwähnen diesen Punkt nochmals, um die Bedeutung zu unterstreichen: Auf Mobilgeräten sind Draw Calls wichtig, selbst ohne den Browser-Overhead. Auch wenn Du nativ mit Unity oder direkt mit GLES entwickelst, musst Du Deine Anzahl an Draw Calls niedrig halten.

Wenn Du eine exzellente WebGL-Performance auf Mobilgeräten erreichen möchtest, solltest Du besonders auf die Anzahl der Draw Calls achten.

WebGL auf Safari 

Auf Safari (sowohl iOS als auch macOS) gibt es zusätzliche WebGL-Anfragen, die mit überraschend hohen Overheadkosten verbunden sind, zum Beispiel:

• bufferSubData()

Achte besonders auf die Verwendung von Uniform Buffers, wenn Du für Safari optimierst.

JavaScript 

Die Sprache für die Schnittstelle mit Browser-APIs wie WebGL ist JavaScript. Der Hauptverursacher von Performanceproblemen mit JavaScript ist die Garbage Collection, die automatisch Speicher identifiziert und entfernt, der nicht mehr benötigt wird.

Der Garbage Collection-Prozess kann die Performance von WebGL-Anwendungen unvorhersehbar und unzuverlässig machen, da Du keine Kontrolle darüber hast, wann er auftritt. Dadurch besteht oft die Möglichkeit, dass er zu ungünstigen Zeiten angewendet wird, was zu Stottern im Rendering führen kann und den Eindruck schlechter Performance vermittelt, selbst wenn der Code sonst gut optimiert ist.

Um stabile Bildraten zu erzielen, solltest Du eine strikte Herangehensweise beim Schreiben von müllfreiem JavaScript verfolgen.

iOS Safari und Speicher 

WebGL-Apps, die gut in Safari laufen, sind selten. Die WebGL-Performance auf Safari bringt einige zusätzliche Herausforderungen mit sich. Wir haben einen ganzen Blog-Post darüber geschrieben, wie man für Safari optimiert.

Speichergrenzen 

Auf iOS steht eine zusätzliche Herausforderung an: Die Browser-Tabs haben sehr begrenzten Speicher, insbesondere auf älterer iPhone-Hardware. Wenn Du die Speichergrenzen überschreitest, kann es sein, dass der Tab neu lädt oder einfriert. Da iPhones einen gemeinsamen Speicher nutzen, wird RAM für CPU und GPU geteilt, und sowohl Textur- als auch Pufferdaten sowie JavaScript oder WebAssembly-Speicher zählen zum Limit.