Canvas-Hardwarebeschleunigung per JavaScript selektiv abschalten

Veröffentlicht am 31. Januar 2023

Der Edge rendert auf manchen Laptops PDFs komisch, wenn Hardwarebeschleunigung an ist, sprach der Kunde zu mir und blickte hoffnungsvoll. Und es stimmte – oft (nicht immer), wenn Edge auf den gerade frisch in seiner Firma ausgerollten Laptops (nicht den alten Laptops) ein PDF in der Inhouse-Webapp zu rendern versuchte, waren einzelne Buchstaben entweder ganz unsichtbar oder es fehlte die Hälfte der relevanten Pixel. Sobald die Hardwarebeschleunigung in den Browser-Optionen abgeschaltet war, sah alles wunderbar aus. Das Problem trat ausschließlich auf den neuen Laptops auf, ausschließlich bei aktivierter Hardwarebeschleunigung und ausschließlich im Edge, bei nicht allen, aber vielen PDFs.

Anders als die initiale Beschreibung des Bugs vermuten lässt, war es gar nicht so schwer, für das Problem einen passenden Workaround zu bauen: einfach die modernsten DOM-APIs mit den übelsten JavaScript-Worst-Practices der Jungsteinzeit kombinieren und schon ist perfektes PDF-Rendering gesichert!

Ursachensuche

Etwas wie der beschriebene Rendering-Bug konnte eigentlich nicht an irgendwelchem JavaScript aus der Feder meines Kunden liegen, da das überwiegend aus pragmatischem Glue Code für diverse Libraries besteht. Also war an der Zeit, die Dependencies zu durchkämmen, was die eigentliche Ursache des Problems schnell zutage förderte. Das PDF-Rendering in der Webapp übernimmt PDF.js (als eine Dependency einer Dependency einer anderen Dependency) und der Bugtracker von PDF.js ist nicht arm an Meldungen des genau gleichen Problems (Beispiel 1, Beispiel 2). Die eigentliche Ursache für den Bug ist aber nicht PDF.js selbst, sondern ein Glitch in der Rendering-Engine des Browsers.

Das Ergebnis der Ursachenforschung ist also: um das Problem wirklich zu reparieren, müssten die C++-Ninjas im Chrome/Blink-Team auf den Plan gerufen werden. Da das, selbst wenn es zeitnah in einem Bugfix münden sollte, vermutlich eine lange Rollout-Phase nach sich ziehen würde, brauchten wir zur Behandlung des akuten Problems einen JavaScript-basierten Workaround. Am einfachsten wäre es, per JS die Hardwarebeschleunigung zu deaktivieren, sollte sich das als machbar herausstellen. Und siehe da: das geht tatsächlich!

Pro und Contra von Canvas-Hardwarebeschleunigung

Im Kontext von Webbrowsern bedeutet Hardwarebeschleunigung, den Hauptprozessor zu entlasten, indem Rendering-Aufgaben an den dezidierten Grafik-Chip (sofern vorhanden) des Rechners übergeben werden. Der Grafik-Chip ist auf Renderei spezialisiert und deshalb darin viel flotter als die generalistische CPU, wovon sowohl CSS als auch Canvas-Elemente profitieren können. Anders als bei CSS ist allerdings Rendering nicht die einzige Aufgabe, die ein Canvas-Element wahrnehmen kann.

Das Canvas-Element unterstützt diverse APIs für Operationen rund um Grafik. Von diesen APIs haben allerdings längst nicht alle etwas mit dem Anzeigen irgendwelcher Pixel zu tun! Wenn wir beispielsweise in JavaScript-Zugriff auf die rohen Pixeldaten von Bilden brauchen, ist das Canvas-Element das Mittel der Wahl:

function loadImage(src) {
  return new Promise((resolve) => {
    const img = new Image();
    img.src = src;
    img.onload = () => resolve(img);
  });
}

// JPEG laden
const img = await loadImage("image.jpg");

// Nicht in DOM eingehängtes Canvas-Element erzeugen
const canvas = document.createElement("canvas");
canvas.width = 300;
canvas.height = 300;

// 2D-API
const ctx = canvas.getContext("2d");

// Bild auf (unsichtbare) Canvas zeichnen
ctx.drawImage(img, 0, 0);

// Pixeldaten abrufen
const imgData = ctx.getImageData(0, 0, canvas.width, canvas.height);

// RGB-Werte invertieren
let i = 0;
while (i < imgData.data.length) {
  imgData.data[i] = 255 - imgData.data[i++]; // r
  imgData.data[i] = 255 - imgData.data[i++]; // g
  imgData.data[i] = 255 - imgData.data[i++]; // b
  i++; // a
}

// Invertierte Pixeldaten auf Canvas zeichnen
ctx.putImageData(imgData, 0, 0);

// Export als Data-URL, Anzeige als Image-Element
canvas.toBlob(async (blob) => {
  document.body.append(await loadImage(URL.createObjectURL(blob)));
});

Wichtig hier: das Canvas-Element ist zu keinem Zeitpunkt sichtbar, da es auch nicht angezeigt werden muss! Wir nutzen seine 2D-APIs (v.a. getImageData()), um die Pixeldaten des geladenen JPEG-Bildes in die Finger zu bekommen, die wir daraufhin invertieren und exportieren. Das Canvas-Element rendert nie etwas sichtbar auf den Bildschirm.

Für diesen Anwendungsfall ist Hardwarebeschleunigung tatsächlich eher Fluch als Segen. Die Benutzung von getImageData() und toBlob() führt dazu, dass bei aktivierter Hardwarebeschleunigung Daten häufig zwischen CPU und GPU hin- und hergeschoben werden müssen, was (je nach Workload) den Vorteil der flotteren GPU zunichtemacht. Damit das nicht sein muss, gibt es mit der Option willReadFrequently ein Opt-Out aus der Hardwarebeschleunigung für 2D-Canvas:

// 2D-API mit Optimierung für Readbacks
const ctx = canvas.getContext("2d", {
  willReadFrequently: true,
});

Der relevante normative Teil der HTML-Spezifikation nennt den Effekt von willReadFrequently nicht direkt ein „ein Opt-Out aus der Hardwarebeschleunigung“, sondern definiert den Effekt als:

When a CanvasRenderingContext2D object's willReadFrequently is true, the user agent may optimize the canvas for readback operations.

Die direkt auf den obigen Satz folgende nicht-normative Anmerkung sowie auch die MDN-Doku zu getContext() nennen das Kind aber beim Namen: willReadFrequently aktiviert Software-Rendering, damit Readbacks schneller werden … und vielleicht auch, damit lästige Rendering-Bugs mit PDF.js verschwinden?

Canvas-Hardwarebeschleunigung per JavaScript selektiv deaktivieren

Es ist nicht die Aufgabe von PDF.js, Rendering-Bugs in Chrome und Chrome-Derivaten zu reparieren. Deshalb ist es gut und richtig, dass in der Library alle Aufrufe von getContext() ohne willReadFrequently daherkommen - der Job von PDF.js ist das zügige Rendern von PDFs und Hardwarebeschleunigung hilft dabei. Aus der Sicht meines Kunden (speziell aus der Sicht der für die Webapp zuständigen Abteilung) ist das freilich anders: Ihr Job ist es, fehlerfrei PDFs in Edge anzuzeigen - und zwar jetzt, nicht erst, wenn Browserbugs gefixt und ausgerollt sind.

Statt PDF.js zu patchen und damit zukünftige Updates der Library zu verunmöglichen, habe ich folgende, dezent haarsträubende Lösung vorgeschlagen:

(function() {
  "use strict";
  const originalGetContext = HTMLCanvasElement.prototype.getContext;
  function patchedGetContext(contextType, contextAttributes = {}) {
    return originalGetContext.call(
      this,
      contextType,
      { ...contextAttributes, willReadFrequently: true }
    );
  }
  HTMLCanvasElement.prototype.getContext = patchedGetContext;
})();

Dieser Code (ummantelt mit einer legacy-konformen IIFE nach Art der Vorväter) überschreibt kurzerhand die getContext()-Methode aller Canvas-Elemente mit einer Variante, die willReadFrequently immer auf true setzt.

Eigentlich versteht sich von selbst, dass man nicht auf diese Weise Prototypen von irgendwelchen Objekten patchen sollte:

Aber keine Regel ohne Ausnahme! Ich würde behaupten, dass der obige Code für das akut bestehende PDF-Render-Problem der am wenigsten schlechte Workaround ist, denn:

  • das betroffene Modul der betroffenen Webapp lebt aus einer Reihe von Gründen in einem Iframe. Dieser bildet eine eigene kleine Sandbox, weswegen nicht alle Canvas-Elemente im kompletten Projekt betroffen sind. Das Team mit dem PDF-Problem verändert nur jene Canvas-Elemente, die es auch verantwortet (wenn auch von diesen Canvas-Elementen tatsächlich alle).
  • selbst wenn alle Canvas-Elemente im Projekt betroffen wären, ist aktuell das schlimmste, was passieren könnte, nachlassende Performance beim Rendering. Langsam, korrekt gerenderte Webapps sind aber besser als schnell falsch gerenderte Webapps, also ist das ein akzeptabler Tradeoff! Zwar könnten zukünftige Änderungen an Standards und Browsern zu Problemen führen, aber ...
  • ...der Code ist für leichtes Löschen optimiert. Er befindet sich in einer Extra-Datei mit einem erklärenden Kommentar inkl. Datumsangabe und Verweis auf den Browser-Bug, der die eigentliche Ursache des Problems ist. Wer auch immer über den Code stolpert, sei es aus Zufall oder auf der Suche nach einem zukünftig entstehenden Problem, kann sofort entscheiden, ob das Modul gelöscht werden kann oder unter welchen Voraussetzungen nach einem neuen Workaround gesucht werden muss.

Für die gegebenen Umstände, unter denen ein akutes Problem schnell und ökonomisch aus der Welt zu schaffen war, halte ich den Code für die perfekt passende Lösung.

Fazit und Ausblick

Nach dem Ausrollen des gezeigten Workarounds ist das PDF-Anzeige-Proble meines Kunden behoben und die Webapp funktioniert, ohne dass die Browser der Nutzer speziell konfiguriert werden müssen. Eine echte Lösung des Problems bestünde in Änderungen an der Rendering-Engine der Browser oder ein Update aller im Unternehmen verwendeten PDFs – beides ist, wenn überhaupt möglich, nicht der Job des Webapp-Teams. Also bleiben nur unglamouröse Workarounds wie das Verändern von PDF.js oder des Canvas-Prototypen. Bei letzterem besteht zumindest eine gute Chance, dass zwischen Einbau und Löschung des Workarounds keine weiteren Probleme auftauchen. Und für den Fall dass doch, sind die Gründe für das Vorhandensein des Workarounds, seine etwas obskure Funktionsweise und die Bedingungen für seine Löschung (inkl. Verweis auf die relevanten Issues in den Bugtrackern der Browser) in Kommentaren lang und breit dokumentiert.

Für mich persönlich war es sehr schön, mal wieder das eingestaubte Wissen rund um Prototypen, this und Function.prototype.call zur Anwendung bringen zu können. In einer Welt, in der katastrophale Browser-Inkonsistenzen selten geworden sind und in der JS-OOP über Klassen extrem einfach geworden ist, kommt man kaum noch dazu, handgeknotete Prototyp-Ketten und Funktionsverbiegungen zu jonglieren. Was zwar alles in allem ein echter und unbestreitbarer Fortschritt ist, aber irgendwo auch ein klein wenig langweilt.

Die famose Fail-Funktion!

Veröffentlicht am 4. Januar 2023

In der Programmierung sind es immer die kleinen Dinge, die einen entweder in die Schreibtischplatte beißen lassen oder das Coding sehr viel angenehmer machen. In die zweite Kategorie fällt für mich die einfache, aber effektive Fail-Funktion. Diese schleppe ich schon seit Jahren mit mir herum und verwende sie in praktisch jedem Projekt oder Experiment, das mehr als 20 Zeilen JavaScript enthält.

Die Fail-Funktion macht nicht viel, leistet aber einiges. Eigentlich besteht sie nur aus drei Zeilen:

function fail(reason, ErrorConstructor = Error) {
  throw new ErrorConstructor(reason);
}

In Worten: die Fail-Funktion wirft einen Fehler! Mit dem optionalen ersten Parameter kann die Fehlermeldung angepasst werden (wird der Parameter ausgelassen, ist die Meldung ein leerer String), der optionale zweite Parameter erlaubt die Wahl des Fehler-Typs. Wenn wir etwas anderes als einen herkömmlichen Error haben wollen, können wir als zweiten Parameter einen alternativen Error-Typ wie z.B. TypeError angeben. Mehr passiert in dieser Funktion nicht!

Wann immer ich die Fail-Funktion anpreise, ernte ich zunächst Unverständnis: warum sollten wir eine Funktion schreiben (oder uns als Dependency ans Bein binden), die nichts tut, als einen Fehler zu werfen? Kann man nicht einfach direkt den Fehler auslösen? Was bringt uns der fail()-Wrapper?

Warum eine Fail-Funktion?

Tatsächlich können wir in JavaScript Stand 2022 nicht „einfach direkt den Fehler werfen“ - zumindest nicht in allen Fällen. Aufrufe der Fail-Funktion können nämlich an Stellen im Programm vorkommen, an denen kein throw-Statement stehen darf. Ein Beispiel zur Verdeutlichung:

let [value] = [];
if (typeof value === "undefined") {
  throw new Error("Got no value!");
}

Dieses Destructuring Assignment soll einen Wert aus einem iterierbaren Objekt (hier einem Array) extrahieren und falls es keinen Wert zum Herausziehen gibt, soll es einen Fehler geben. Mit der Fail-Funktion lässt sich das Gleiche in viel kürzer ausdrücken:

let [value = fail("Got no value!")] = []; // Error: Got no value!

Für Destructuring Assignments können wir in JavaScript seit Anbeginn der Zeiten Default-Werte angeben und es greift hier lazy evaluation: Die JavaScript-Engine schaut sich die rechte Seite des Gleichheitszeichens nur an, wenn sie auf der linken Seite ein undefined vorfindet. Normalerweise ist die Idee, der linken Seite einen Standard-Wert mitzugeben ...

let [value = 42] = []; // value === 42

... damit value niemals leer ausgeht. Doch wir können stattdessen, wenn wir keinen Default-Wert vergeben wollen, mithilfe der Fail-Funktion über den gleichen Mechanismus einen Fehler auslösen! Auf diese Weise können wir kompakt und bequem erzwingen, dass das Array immer mindestens einen Wert enthält (und dieser Wert in der Variable value landet).

Die Fail-Funktion kann diese Aufgabe übernehmen, weil ein Funktionsaufruf ein Ausdruck ist, während throw ein Statement ist (ersteres produziert einen Wert, zweiteres nicht; siehe Dr. Axels Erklärung zum genauen Unterschied). Und ein Ausdruck darf in JS-Programmen an vielen Stellen stehen, an denen ein Statement nichts verloren hat. Der folgende Code versucht, mittels eines direkten throw-Statements das Gleiche wie die Fail-Funktion zu erreichen, ist aber Stand 2022 syntaktisch nicht zulässig:

// SyntaxError
let [value = throw new Error("Got no value!")] = [];

Der Wert der Fail-Funktion besteht also kurz gesagt darin, dass sie ein Statement in einen Ausdruck verpackt und damit syntaktisch legalisiert, was normalerweise nicht erlaubt ist.

Der universeller Happy-Path-Eingrenzer

Die Preisfrage bei dem obigen Destructuring-Beispiel ist natürlich: hilft uns die Fail-Funktion an dieser Stelle, oder macht sie einen einfachen Programmablauf (wenn kein Wert, dann ein Fehler) im Vergleich zu einem If-Statement nicht eher kryptisch und übermäßig kompakt? Ich würde das mit Vehemenz bestreiten! Zahlreiche Szenarien sind mit der Fail-Funktion viel bequemer auszudrücken als auf jede andere Weise.

Szenario 1: eine Funktion mit drei Pflichtparametern:

function requiresThreeArguments(a, b, c) {}

Wie können wir sicherstellen, dass die Funktion auch tatsächlich mit allen drei Parametern aufgerufen wurde? In JavaScript hält uns im Prinzip nichts davon ab, beliebige Funktionen mit beliebig vielen beliebigen Parametern aufzurufen - ein Parameter wird erst dann zu einer Pflichtangabe, wenn wir ihn in der Funktion entsprechend überprüfen. Und das könnten wir über diverse Permutationen von If-Abfragen bewerkstelligen:

function requiresThreeArguments(a, b, c) {
  if (typeof a === "undefined") {
    throw new Error("a is required");
  }
  if (typeof b === "undefined") {
    throw new Error("b is required");
  }
  if (typeof c === "undefined") {
    throw new Error("c is required");
  }
}

Wenn wir der Meinung sind, auf sinnvolle Fehlermeldungen verzichten zu können (warum sollte man auch wissen wollen, welcher Parameter fehlt?), können wir die If-Kaskade auf ein einziges Statement eindampfen:

function requiresThreeArguments(a, b, c) {
  if (typeof a === "undefined" || typeof b === "undefined" || typeof c === "undefined") {
    throw new Error("something is missing");
  }
}

Besonders brillant finde ich weder die erste, noch die zweite Variante. Entweder ist es mir deutlich zu viel Code (Variante 1) oder die Fehlermeldungen sind zu unspezifisch (Variante 2). Und eigentlich ist mir auch Variante 2 zu viel Code! Ich möchte einfach nur - ohne zu TypeScript greifen zu müssen - eine Annotation an den Funktionsparametern haben, statt den Funktionsblock mit zusätzlichem Code zu verlängern. Aber zum Glück haben wir ja die Fail-Funktion!

function requiresThreeArguments(
  a = fail("a is required"),
  b = fail("b is required"),
  c = fail("c is required")
) {}

Das ist nicht nur in den meisten Fällen einfach kürzer, sondern bereinigt vor allem den Funktionsblock! Um das ganze noch etwas zu perfektionieren, könnten wir von fail() eine Variante ableiten, die einen schöneren Namen hat und standardmäßig einen passenderen TypeError durch die Gegend wirft:

const required = (reason) => fail(reason, TypeError);

function requiresThreeArguments(
  a = required("a is required"),
  b = required("b is required"),
  c = required("c is required")
) {}

Kompakt, lesbar und mit minimalen JavaScript-Bordmitteln umgesetzt, was will man mehr?

Das Konzept lässt sich auch bequem auf Objekte aller Art anwenden:

// Im Destructuring Assignment
let [value = fail("Got no value!")] = someIterableObject;

// Bei normalem Objektzugriff in Kombination mit ??
let value = someObject.value ?? fail("Got no value!")];

// Bei Maps in Kombination mit ??
let value = someMap.get("key") ?? fail("Got no value!")];

Gerade wenn wir doch mal in TypeScript unterwegs sind, ist die Fail Funktion in Kombination mit dem Nullish coalescing operator (??) Gold wert.

Die Fail-Funktion für TypeScript

Mit TypeScript-Typannotationen sieht die Funktion wie folgt aus:

export function fail(reason?: string, ErrorConstructor = Error): never {
  throw new ErrorConstructor(reason);
}

Der Rückgabetyp never der Funktion ist dabei der Schlüssel für Type Narrowing. Wird eine Funktion mit Rückgabetyp never aufgerufen, weiß TypeScript, dass das Programm in Folge nicht mehr weitergeht. Unter anderem wäre das der Fall, wenn eine Endlosschleife betreten wird oder wenn ein Fehler geworfen wird. Und wenn die Frage, ob das Programm weiter geht oder nicht, mit dem Typ einer bestimmten Variable zusammenhängt, dann ...

declare var myFoo: { value: number | undefined };

let val1 = myFoo.value;
// Typ von val1: number | undefined

let val2 = myFoo.value ?? fail();
// Typ von val2: number

Der Typ von val2 ist number, da fail(), wenn aufgerufen, zum Ende Programms führt - und das passiert nur, wenn myFoo.value entweder null oder undefined ist. Ist myFoo.value etwas anderes, wird die rechte Seite von ?? nicht ausgeführt und der Nachweis ist erbracht, dass val2, vom Typ number sein muss. Andernfalls würde das Programm (oder zumindest die aktuelle Funktion) per Error abrupt enden, was TypeScript problemlos nachvollzieht. Type Narrowing in Aktion!

Das ist nützlich, da das strikte Typsystem manche Programmabläufe nicht nachvollziehen kann und deshalb manchmal sehr vorsichtig mit der Typvergabe ist. Ein absolutes Extrembeispiel:

let map = new Map<string, number>();
map.set("key", 42);
let result = map.get("key");
// Typ von result: number | undefined

Es gibt keine Macht auf diesem Planeten, die verhindern kann, dass in diesem Beispiel result am Ende des Tages 42 enthält. Der Programmablauf kann unter keinen Umständen dazu führen, dass am Ende für map.get("key") ein undefined herauskommt, aber das ist nur klar, wenn wir alle drei Zeilen auf einmal betrachten und wissen, dass zwischendurch nichts anderes mit der Map passiert. Wir könnten natürlich eine Zeile einfügen, die das Undefined-Risiko wieder heraufbeschwört ...

let map = new Map<string, number>();
map.set("key", 42);
if (Math.random() < 0.1) { // Yolo
  map.delete("key");
}
let result = map.get("key");
// Typ von result: number | undefined

... aber wenn wir das nicht machen, wissen wir, dass result eine Zahl enthalten wird und TypeScript übervorsichtiges number | undefined steht uns im Weg herum. Was tun? Fail-Funktion benutzen!

let map = new Map<string, number>();
map.set("key", 42);
let result = map.get("key") ?? fail();
// Typ von result: number

Die Fail-Funktion erreicht an dieser Stelle zwei Dinge. Zum einen betreibt sie Type Narrowing. Dank der never-Rückgabetyp-Annotation der Fail-Funktion weiß TypeScript, dass das Programm endet, wenn sie aufgerufen wird und da das nur passiert, wenn auf der linken Seite von ?? entweder null oder undefined steht, weiß TS, dass wenn das Programm nicht endet, in result weder null noch undefined stehen können. Aus dem eigentlichen number | undefined, das wir aus get() bekommen, wird also number. Und sollte, auf welche Weise auch immer, für result wirklich einmal keine Zahl herauskommen, gibt es einen Fehler, der uns sofort zur verantwortlichen Zeile führt. Auf diese Weise führt die Fail-Funktion zu einem Zugewinn an Sicherheit (verglichen mit einer Type-Assertion as number) und, per Type Narrowing zu einer Verbesserung der Ergonomie. Win-Win!

Fazit und Ausblick

Obwohl die Fail-Funktion nur drei Zeilen hat, leistet sie viel: Code wird kompakter, sicherer und (im Kontext von TypeScript) sehr viel weniger lästig. Ist die Fail-Funktion also uneingeschränkt großartig und sollte von uns allen stets und ständig verwendet werden? Stand jetzt schon, aber sie könnte in Zukunft überflüssig werden.

Das Einzige, was noch besser als die Fail-Funktion wäre, wäre wenn wir ohne eine Extra-Funktion Fehler an Ausdrucks-Positionen werfen könnten und TC39 arbeitet tatsächlich an einem entsprechenden Feature! Die neue throw-Expression ließe sich genau so verwenden wie die Fail-Funktion, wäre aber ein neues, natives Feature:

function requiresThreeArguments(
  a = throw new TypeError("a is required"),
  b = throw new TypeError("b is required"),
  c = throw new TypeError("c is required")
) {}

throw in diesem Kontext sieht genau so aus, wie ein throw-Statement, ist aber ein Ausdruck und daher technisch gesehen etwas anderes. Benutzen ließe sich aber beides auf die gleiche Weise. Throw-Expressions hätten diverse kleine Vorteile gegenüber der Fail-Funktion und würden nur überschaubare Anpassungen an der ECMAScript-Grammatik benötigen. Da das Proposal aber nun schon seit Jahren im Limbo zwischen Stage 2 und 3 herumeiert, werden wir bis auf Weiteres der Fail-Funktion bleiben müssen.

How to Center in CSS, Scrollbar Edition

Veröffentlicht am 30. November 2022

Der älteste Witz des bekannten Webdev-Universums besteht darin, dass es nicht komplett trivial ist, Elemente mit CSS vertikal zu zentrieren. Dieser Witz ist spätestens seit Frühjahr 2021, als mit dem Internet Explorer 11 der letzte nicht perfekt Flexbox unterstützende Browser auf das Abstellgleis befördert wurde, hinfällig. Seither, so wissen wir alle, könnte es einfacher nicht sein:

.wrapper {
  display: flex;
  align-items: center;
}

Flexbox (und Grid) bieten direkte Unterstützung für vertikale Zentrierung und das Problem ist damit ein für allemal komplett erschlagen. Außer per Flexbox und Grid ist Zentrierung außerdem mit absoluter Positionierung und einer Transformation zu erreichen. Dieses Verfahren braucht ein paar Zeilen mehr, ist dafür aber auf dem zu zentrierenden Element statt auf dessen Container anzuwenden:

.wrapper {
  position: relative;
}

.element {
  position: absolute;
  top: 50%;
  transform: translateY(-50%);
}

Diese Variante, die sich zunutze macht, dass sich Prozentangaben bei Transformationen auf die Maße des Elements statt auf die des Containers beziehen, hat den Vorteil, dass durch die Angabe von left und translateX en passant auch eine horizontale Zentrierung zu machen ist. Beide Varianten funktionieren ganz ausgezeichnet … solange das zu zentrierende Element kleiner (für vertikale Zentrierung: weniger hoch) ist, als sein Elternelement. Aber was, wenn nicht?

Vertikale Zentrierung schlägt Scrollbalken

Nehmen wir einmal an, wir wollten ein Element variabler Größe innerhalb eines Containers darstellen. Das Element soll in unserem Beispiel vertikal zentriert sein, solange dafür der Platz ausreicht und wenn der Container für sein Element zu klein ist, sollen Scrollbalken auf dem Container die Möglichkeit bieten, das komplette Element zu betrachten. Auf diese Weise könnte etwa ein Grafikprogramm, bei kleinen Zoomstufen die gesamte Malfläche darstellen und bei starker Vergrößerung vertikales und/oder horizontales Scrollen ermöglichen.

Das klingt zunächst ganz einfach, Scrollbalken in Webseiten sind schließlich kein Hexenwerk: Wir müssen nur dem Container overflow:auto verpassen, und schon taucht (wenn nötig) das gewünschte Scroll-UI auf. Problem gelöst! Es sei denn, wir wollen scrollen und vertikal zentrieren:

Links ein vertikal zentriertes Element, das oben und unten aus seinem kleineren Container herausläuft. Rechts hat der Container scollbalken, doch der oben überstehende Teil des Kindelements ist trotzdem abgeschnitten.

Das sieht gar nicht mal so gut aus! Die horizontale CSS-Zentrierung ist offenbar unverwüstlich und zentriert auch das, was eigentlich nicht mehr in seinen Container passt. Die Mitte des Containers und die Mitte des zu zentrierenden Elements (die Rot-Blau-Grenze) liegen aufeinander und wenn der Container weniger hoch als sein Inhalt ist, läuft es oben und unten über die Grenze seines Elternelements. So weit, so erwartbar. Der mit overflow: auto hinzugefügte Scrollbalken macht aber nur den unteren über den Rand laufenden Teil des zu großen Elements erschließbar! Alles, was oben übersteht, der gesamte überstehende rote Anteil, wird einfach abgeschnitten und ist komplett unerreichbar (man achte auf die Scroll-Position des rechten Containers im obigen Bild). Möglicherweise wichtiger Inhalt verschwindet auf diese Weise komplett im Overflow-Orkus. Das kann so nicht bleiben!

Eine Formel für bedingte vertikale Zentrierung … mit Nachteilen

Um unser Ursprungsziel zu erreichen, benötigen wir im Prinzip eine bedingte vertikale Zentrierung, die nur bei ausreichend Platz greift. Sobald der zu zentrierende Inhalt zu groß für seinen Container wird, muss der Zentrierungsmechanismus seine Arbeit einstellen und das Element normal an die obere linke Ecke seines Containers andocken, damit der Scrollbalken seine Arbeit verrichten kann. Am einfachsten geht das, indem wir

  1. Anstelle von Flexbox oder Grid als Zentrierungsmechanismus position:absolute wählen
  2. top mithilfe von calc() errechnen, statt einfach top:50% zu verwenden und für die Maße des Elements mit transform: translateY(-50%) zu kompensieren
  3. Einen Top-Overflow unterbinden, indem wir das calc()-Ergebnis aus Schritt 2 mithilfe von max() auf mindestens 0px beschränken

Im Endeffekt:

.element {
  top: max(0px, calc((100% - 600px) / 2));
}
Links die schlechte Scroll-Lösung aus dem vorherigen Beispiel, rechts die bessere Lösung nach der neuen Formel.

Der erste Parameter für max() ist der für uns nicht zu unterschreitende Top-Offset von 0px, während der zweite Parameter unser eigentlicher Wunsch-Offset ist. Für vertikale Zentrierung ist das die Hälfte des Platzes, der übrig bleibt, wenn wir von der Höhe des Containers (100%) die Höhe des zu zentrierenden Elements (im Beispiel 600px) abziehen. Das Ergebnis des calc()-Ausdrucks wird negativ, wenn des zu zentrierende Element höher als sein Container ist, aber vor diesen Auswirkungen bewahrt uns die Limitierung auf mindestens 0px. Im schlimmsten Fall, bei zu wenig Platz, dockt das Element also oben an und ist auf ganzer Höhe erscrollbar.

Der Haken an dieser Lösung: die Maße des zu zentrierenden Elements müssen bekannt sein. Prozentangaben in top beziehen sich auf das Elternelement und können sich auch auf nichts anderes beziehen; durch die Angaben wie top (ggf. kombiniert mit left, bottom und right) ergeben sich die Maße des Elements schließlich erst. Die Höhe des bedingt zu zentrierenden Elements müssen wir also kennen und in die „Formel“ für top eintragen.

Grundsätzlich könnten wir die top-Formel auch in der transform-Eigenschaft verwenden, haben dort dann aber das umgekehrte Problem: Wir müssten die Dimensionen des Elternelements kennen und fest eintragen. Prozentangaben in transform-Werten beziehen sich auf das betroffene Element selbst, denn eine Transformation ist nur eine Veränderung des Koordinatensystems für die zu zeichnenden Pixel. Deshalb bleibt der „Platzverbrauch“ eines Elements vor und nach einer Transformation gleich; die Pixel sind transformiert, doch das CSS-Layout bleibt, wie es war:

Ein per CSS transformiertes, von CSS umflossenes Quadrat demonstriert, dass nur das Rendering eines Elements verändert wird, das eigentliche Layout jedoch nicht.

Egal ob wir die Verschiebung des Elements per Transformation oder per top versuchen, komplette Flexibilität ist nicht drin   entweder, die Maße des Containers oder des zu zentrierenden Kindelements müssen wir kennen. Es sei denn, wir verwenden ein ganz bestimmtes Feature aus dem Dunstkreis der nagelneuen Container Queries!

Eine flexiblere Formel für bedingte vertikale Zentrierung

Container Queries sind im Prinzip Media Queries für Elemente – Queries, die sich nicht auf der Maße des Bildschirms, sondern auf die Eigenschaften ausgewählter Elternelemente (der Query Container) beziehen. Container Queries sind aber nicht einfach nur ein Standard für besseres Responsive Design, sondern führen auch eine Reihe von interessanten neuen Einheiten ein:

  • cqw: 1% der Breite eines Query Containers
  • cqh: 1% der Höhe eines Query Containers
  • cqi/cqb: 1% Der Inline- bzw. Block-Größe eines Query Containers
  • cqmin/cqmax: Der kleinere bzw. größere Wert von cqi und cqb

Das bedeutet: in einer CSS-Transformation eines Elements haben wir, wenn sein Elternelement ein Query-Container ist, sowohl die Maße des Elements selbst (als %) als auch die des Elternelements (als cqw bzw. cqh) zur Hand! Die top-Formel, entsprechend adaptiert und in transform verwendet, kann damit das Element in eine zentrierte Position verschieben. Das Elternelement muss nur noch zum Query-Container erklärt werden (damit sich cqw und cqh auf etwas beziehen können) und schon klappt es:

.wrapper {
  container-type: size; /* Maße von .wrapper definieren cqh/cqw */
  overflow: auto;
}
.wrapper .element {
  transform: translateY(max(0%, calc((100cqh - 100%) / 2)));
}

Selbst wenn sich die Maße von Container oder Content ändern, das Element bleibt zentriert und die Scrollbalken greifen, wenn nötig, ein! Besonders charmant finde ich an dieser Lösung den Grund für das Erscheinen und Verschwinden der Scrollbalken. Das Element wird zwar zentriert, doch da dies per Transformation geschieht, manifestiert sich der „Platzverbrauch“ des zentrierten Elements durchgehend an der linken oberen Ecke. Wird das Elternelement zu klein, findet sich auch die Transformation der Darstellung an dieser Position ein und - da ab dann der Platzverbrauch auch größer als der umgebende Container ist - die Scrollbalken tauchen auf. Keine Tricks jenseits der Transformation notwendig!

Fazit, Nachteile und Browserunterstützung

Wo sind die Haken bei dieser Lösung? Container Queries fehlen stand Dezember 2022 noch im Firefox. Support im Nightly Build ist schon da, aber noch nicht im regulären Release. Die Transformation bildet natürlich einen neuen Stacking Context und die Angabe von container-type auf dem Wrapper-Element aktiviert implizites Layout-, Style-, und Size-Containment. Das alles, abgesehen vom Firefox-Support, sind keine echten Haken, sondern fallen eher in die Kategorie der zu beachtenden Dinge. Ein reiner Selbstläufer ist das vertikale Zentrieren mit CSS dann doch nicht, jedenfalls nicht, wenn Scrollbalken ins Spiel kommen. Der älteste Witz des bekannten Web-Universums ist und bleibt auch Ende 2022 noch ein ganz klein wenig relevant.

100.000 MutationObserver vs. 100.000 Funktionen

Veröffentlicht am 6. Juli 2021

Ist die Performance eines MutationObserver mit 100.000 Callbacks besser als die Performance von 100.000 MutationObservers mit je einem Callback? Und wenn ja, wie groß ist der Unterschied? Diese Frage tat sich vor mir auf, als ich einst an einer Browser-Extension schraubte, die das DOM einer Seite überwacht und in diesem Kontext sind sowohl Performance als auch MutationObserver wichtig. Also habe ich ein paar Experimente gestartet, die nicht nur eine Antwort auf die Ausgangsfrage, sondern auch einige Erkenntnisse zu den Unterschieden zwischen den diversen Browsern zutage geführt haben. Und weil der ganze Prozess ein ziemlich gutes Beispiel für zielgerichtete Performance-Forschung im Entwickler-Alltag ist, will ich meinen Weg zum Ergebnis in diesem Post nachzeichnen. Falls das uninteressant ist, geht's hier direkt zum Fazit.

MutationObserver

Der MutationObserver ist im modernen Browser das Mittel der Wahl um über Änderungen am DOM im Bilde zu bleiben. Die API ist überschaubar, aber gewöhnungsbedürftig:

// Ziel der Überwachung
const targetNode = document.querySelector(".foo");

// Optionen der Überwachung
const config = { attributes: true, childList: true };

// Handler-Funkion
const callback = function(mutations) {
  for(const mutation of mutations) {
    if (mutation.type === "childList") {
      console.log("Inhalt geändert");
    } else if (mutation.type === "attributes") {
      console.log("Attribut " + mutation.attributeName + " geändert");
    }
  }
};

// Setup
const observer = new MutationObserver(callback);

// Start
observer.observe(targetNode, config);

// Ende via observer.disconnect()

Die etwas komplizierte Konstruktion von MutationObserver wurde aus Performance- und Stabilitätsproblemen mit Mutation Events geboren. Die Mutation Records (die Parameter der Handler-Funktion) trudeln asynchron ein und werden gebündelt, so dass auch ein größeres innerHTML, das viele DOM-Nodes durch andere Nodes ersetzt, nur einen einzigen Funktionsaufruf verursacht. In den Überwachungs-Optionen lässt sich festlegen, ob nur das Ziel-Element überwacht wird, oder ob auch dessen gesamter Sub-Tree betrachtet werden soll und welche Änderungen (Attribute, Text, Kind-Elemente) mitgeschnitten werden sollen.

Alles schön und gut, aber wie sehen die Performance-Charakteristika von MutationObservers aus?

Gibt es überhaupt ein Performance-Problem mit MutationObserver?

Mit modernem Browser-Tooling können wir bei der JavaScript-Performance-Analyse extrem tief ins Detail gehen, doch der erste Schuss sollte eigentlich immer dem Prinzip „stumpf ist Trumpf“ folgen. Wir bilden eine möglichst einfache Hypothese, die, wenn zutreffend, alle weiteren Untersuchungen überflüssig macht. Und dann versuchen wir, diese Hypothese in einem möglichst einfachen Experiment zu widerlegen. Sollte das gelingen, müssen wir weitere Untersuchungen anzustellen und/oder die Hypothese anpassen, während wir, wenn die Hypothese auf die erste Beobachtung passt, nichts weiter zu untersuchen haben.

Für diese erste Messreihe genügt der folgende, extrem billige Versuchsaufbau:

// Gewagte Hypothese: 100.000 MutationObserver sind kein Problem

let result = 0;
let target = document.querySelector("div");

for (let i = 0; i < 100000; i++) {
  new MutationObserver(function handler() {
    result++;
  }).observe(target, { attributes: true });
}

document.querySelector("button").onclick = () => {
  target.setAttribute("data-test", "1")
  setTimeout(() => console.log(result), 3000);
};

Einfacher kann's nicht werden: das Programm kommt als Inline-Script in ein HTML-Dokument mit einem <div> und einem <button> und fertig! Die Handler-Funktion zählt eine später ausgegebene Variable hoch, damit die JavaScript-Engines nicht auf die Idee kommen, den gesamten Code (der ohne diese Variable keine wahrnehmbare Auswirkung hätte) einfach wegzuoptimieren. Als Nächstes sollten wir den Versuchsaufbau in einem privaten Tab öffnen (kein Cache, keine Browser-Extensions) und mit den Devtools messen, ob sich irgendwelche Performance-Auffälligkeiten einstellen, doch in diesem Fall ist bereits beim Laden der Seite, noch vor dem Nachmessen, klar, dass es keine gute Idee sein kann, 100.000 MutationObserver zu betreiben:

Anscheinend braucht mein relativ neuer Desktop-PC mit seinen über 9000 CPU-Kernen mehr als 4 Sekunden um 100.000 einfachstmögliche MutationObserver in einer einfachstmöglichen Webseite einfach nur zu starten ‐ und hier wird nur das oben gezeigte Inline-Script evaluiert, zu einer DOM-Mutation kam es noch gar nicht! Die Test-Webseite von der lokalen Festplatte zu laden dauerte bereits spürbar lang, da das Inline-Script den HTML-Parser blockierte. Damit ist auf jeden Fall schon mal geklärt, dass MutationObserver für Performance nicht per se egal sind. Wir können außerdem erkennen, dass der Löwenanteil der vergangenen Zeit (self time) auf das Starten der Observation, d.h. den Aufruf von observe() entfällt.

Triggern wir per Button-Klick eine DOM-Mutation, so sehen wir einen mit 0,5 Sekunden recht stattlichen Trödel-Block in den Microtasks, worin sich das eigentliche MutationObserver-Geschehen abspielt:

Das ist nicht so absurd viel (denn es sind immerhin 100.000 MutationObserver), aber es ist auch nicht nichts. Unsere Ausgangshypothese, nach der 100.000 MutationObserver keinen wirklichen Einfluss auf die JS-Performance haben, ist damit dahin und wir dürfen weiterforschen.

Als Nächstes ist natürlich die Gegenprobe mit 100.000 Funktionen und einem einzigen Observer angesagt, die in einem ähnlich simplen Versuchtsaufbau stattfindet:

// Hypothese: 100.000 Funktionen sind genau so lahm wie 100.000 Observer

let result = 0;
let target = document.querySelector("div");

let handlers = [];

for (let i = 0; i < 100000; i++) {
  handlers.push(function handler() {
    result++;
  });
}

new MutationObserver(function rootHandler() {
  for (const handler of handlers) {
    handler();
  }
}).observe(target, { attributes: true });

document.querySelector("button").onclick = () => {
  target.setAttribute("data-test", "1");
  setTimeout(() => console.log(result), 3000);
};

Non-Arrow-Functions sind bei Performance-Tests immer sehr praktisch, da wir ihnen problemlos Namen verpassen können, die ihrerseits das Profiling-Ergebnis besser lesbar machen. Das Programm bauen wir wieder als Inline-Script in ein einfaches HTML-Dokument ein, laden im privaten Tab und messen nach:

Diese Variante ist so schnell, dass die Messung der Laufzeiten des Mutations-Microtasks gerade so erfasst wurde, während der einmalige Aufruf von observe() im Profiling noch nicht mal auftaucht. Damit scheint die Ausgangsfrage beantwortet: Es gibt einen nicht nur mess-, sondern sogar spürbaren Unterschied zwischen einem Observer mit N Callbacks und N Observern mit einem Callback. Zeit für den Feierabend?

Generelles Phänomen oder Browser-Spezialität?

Die bisherigen Versuche haben alle nur in Chrome stattgefunden, doch es gibt (Stand Mitte 2021) noch ein paar weitere Browser, die nicht Chromium-basiert sind. Es lohnt sich, die Versuche auch dort zu reproduzieren, um auszuschließen, dass wir es mit Chrome-Bugs zu tun haben. Öffnen wir also den 100.000-Observer-Versuch in Firefox und messen mal nach, ob dort auch mehrere Sekunden für observe() ins Land gehen:

Dieser hier 161 Millisekunden dauernde „Funktionsaufruf“ ist kein Funktionsaufruf im eigentlichen Sinne, sondern die Gesamtheit des Inline-Scripts (quasi dessen main()-Funktion). Wo also Chrome allein 4 Sekunden benötigt, um 100.000-mal observe() zu starten, macht Firefox den gleichen Job plus alles andere (z.B. 100.000-mal new MutationObserver()) in einem Bruchteil der Zeit. Das ist schon ein ausgesprochen bemerkenswerter Unterschied – kann es sein, dass in Chrome ein Bug schlummert, der observe() besonders langsam macht? Die Antwort wird offenbar, wenn wir im Firefox eine erste DOM-Mutation auslösen:

Oh, 21 Sekunden für das Click-Event, das die DOM-Änderung verursacht!? Sportlich! Es sieht aus, als würden Chrome und Firefox einen Teil der Arbeit, die bei oder zwischen observe() und der ersten DOM-Mutation anfällt, zu unterschiedlichen Zeitpunkten ausführen. Offenbar wird einiges an Arbeit, das in Chrome beim Aufruf von observe() stattfindet, im Firefox erst dann ausgeführt, wenn tatsächlich ein zu observierendes Ereignis stattfindet. Um welche Arbeit es sich dabei genau handelt, vermag ich den Spezifikationen nicht zu entnehmen, was nahelegt, dass es sich um ein reines Implementierungsdetail handelt. Beide Browser setzen die Standards korrekt um, nehmen aber unterschiedliche Wege zum Ziel (was durchaus nicht ungewöhnlich ist). Firefox versucht, den Start des Observers zu optimieren, indem Arbeit aufgeschoben wird, während Chrome probiert, nach einmaligen (vergleichsweise langsamen) Observer-Setup den ersten Callback-Aufruf möglichst flott zu gestalten.

Festzuhalten bleibt: einen MutationObserver zu starten ist keine Kleinigkeit, auch wenn sich der Effekt in verschiedenen Browsern unterschiedlich manifestiert.

Wie groß ist das Problem wirklich?

Die bisherigen Versuchsaufbauten haben erst mal nur gezeigt, dass MutatationObserver für JavaScript-Performance relevant sind, wenn sie zu tausenden gestartet werden. Was ist aber, wenn es nur hunderte oder gar noch weniger Observer gibt? Eine ermüdende Messreihe (durchgeführt mit Chrome auf einem neuen Desktop-Ryzen ohne Drosselung o.Ä.) führt zu folgendem Bild:

Alles unterhalb von 1000 Observern ist nicht messbar. Darüber steigt die Laufzeit für observe() an, wobei es erst ab 10.000 wirklich kritisch wird. Das wären nicht unmöglich viele Observer, aber auf jeden Fall extrem viele. Unterhalb dieser Extrem-Grenze gibt es also kein wirkliches Problem damit, viele MutationObserver zu betreiben.

Was im Übrigen keine signifikante Rolle zu spielen scheint, ist die Komplexität der observierten DOM-Struktur. Egal wie viele Elemente sich innerhalb oder im Umfeld des Observations-Zieles befinden, der Effekt ist nahezu nicht messbar.

Fazit

Die Ausgangsfrage „ist die Performance eines MutationObserver mit 100 Callbacks besser als die Performance von 100 MutationObservers mit je einem Callback?“ lässt sich also wie folgt beantworten:

  1. Ein MutationObserver, dessen Callback viele Funktionen aufruft, performt grundsätzlich besser als viele MutationObservers mit je einem Callback.
  2. Ein signifikanter Unterschied tritt nicht bei Mutation Events an sich auf, sondern beim Starten der Observation. Im Firefox scheint das „starten der Observation“ beim ersten Mutation Event stattzufinden und nicht, wie in Chrome, beim Aufruf von observe(). Ab dem ersten Aufruf zeigen beide Browser das gleiche Verhalten.
  3. Insgesamt ist die Performance des MutationObserver auf modernen Geräten so gut, dass sich die Unterschiede bei weniger als 1000 Observern nicht wirklich zu Buche schlagen.

Als Best Practices für MutationObservers können wir festhalten:

  1. Es ist kein Problem, 10 oder 20 MutationObserver auf einmal zu betreiben
  2. Falls es sich für den aktuellen Use Case anbietet, könnte das Event-Delegation-Pattern auf MutationObserver angewendet werden: einfach den Document Root observieren, subtree auf true stellen und im Callback je nach betroffenem Element verfahren.
  3. Falls jede Millisekunde zählt, aber DOM-Updates nicht ab Laden der Seite zu erwarten sind, könnte der Aufruf von observe() aus dem Critical Path genommen werden, z.B. via requestIdleCallback(). Firefox macht das quasi von sich aus (schiebt die Arbeit zum ersten Mutation Event), aber mit requestIdleCallback() oder anderen Aufschieb-Mechanismen können wir eine vergleichbare Optimerung auch in anderen Browsern umsetzen.

Im Klartext: modernes JavaScript/DOM ist so schnell, dass MutationObserver per se kein Performance-Problem darstellen, selbst wenn wir hunderte von ihnen auf einmal betreiben. Zwar sind Einzel-Observer messbar schneller, aber der Unterschied ist zu vernachlässigen, solange wir keine vollends absurden Mengen von Observers zu Felde führen. Würde ich nach Möglichkeiten suchen, mein Web-Projekt schneller zu machen, würde ich mich zuerst um andere Baustellen kümmern.