e2e-Check pixel-art filtering in 12-textures fällt gelegentlich, im Nachlauf grün.
Stand: fällt mit gpu:"none", uploaded:false. Ausgeschlossen: der Filterpfad selbst, 30 Wechsel in einer Sitzung, Kontextverlust. Verdacht: Timing/Umgebung.
Messgerät: __gm.textureFilter(datei) (Modellwert und Treiberzustand).
Übernommen aus todo-notes/flaky-pixel-art-filtering.md beim Umzug auf das Issue-System (2026-09-12).
Angelegt: 2026-09-11 · bf41919 — Add todo notes for the next round of features, gaps and upkeep
Gemeldet von: Claude (Assistent)
e2e-Check `pixel-art filtering` in `12-textures` fällt gelegentlich, im Nachlauf grün.
Stand: fällt mit `gpu:"none", uploaded:false`. Ausgeschlossen: der Filterpfad selbst, 30 Wechsel in einer Sitzung, Kontextverlust. Verdacht: Timing/Umgebung.
Messgerät: `__gm.textureFilter(datei)` (Modellwert und Treiberzustand).
---
*Übernommen aus `todo-notes/flaky-pixel-art-filtering.md` beim Umzug auf das Issue-System (2026-09-12).*
- **Angelegt:** 2026-09-11 · `bf41919` — Add todo notes for the next round of features, gaps and upkeep
- **Gemeldet von:** Claude (Assistent)
Befund (2026-09-12) – nicht reproduzierbar, Umgebung ist weg
Alle drei aufbewahrten Fehlschläge stammen vom Remote-Windows-Browser (Testinger@192.168.100.150) am 09.09. (13:02, 13:43, 22:13). Signatur in allen drei identisch: beide Messungen (nearest und linear) liefern dieselben verwaschenen Pixel #c65641 #a67047 #868a4c #66a552 #3cc85a, Drift 0; der Lauf mit Treiber-Sonde meldet scaleMode:"nearest", gpu:"none", uploaded:false.
Der Remote-Browser war an dem Tag generell flatterhaft: in 11 von ~40 Remote-Läufen fielen auch unzusammenhängende Checks (Hierarchie-Falten, Node löschen, Doppelklick, Undo, Palette-Drop, Nesting) – jeweils im Nachlauf grün. Der Launcher lief headless mit --ignore-gpu-blocklist auf der Windows-Karte.
Lokal (chromium, erzwungene GPU, seit 11.09. desynchronized WebGL-Kontext): 0 Fehlschläge in allen ~50 vollen Läufen seit dem 10.09., jedes Mal gpu:"nearest", uploaded:true. Die Remote-Maschine steht auf absehbare Zeit nicht zur Verfügung.
Geprüft und ausgeschlossen (Pixi 8.20.1):
Listener-Verlust nach Textur-GC: GCManagedHash.remove setzt den Eintrag auf null, ein erneutes add hängt styleChange wieder an.
Ein Tausch oder destroy der Textur-Quelle im eigenen Code: gibt es nicht; Sprite-Views, Texture-Tab und Picker teilen sich die eine TextureLibrary-Map.
Bereits früher: Filterpfad selbst, 30 Wechsel in einer Sitzung, Kontextverlust.
Was die Signatur sagt und was nicht:uploaded:false heißt, die Bibliotheks-Textur lag zum Messzeitpunkt nicht auf der GPU, während der Schirm ein (linear gefiltertes) Bild zeigte. Für eine Textur, die jedes Frame gezeichnet wird, passt das nicht zusammen – ohne die Maschine nicht erklärbar.
Blinder Fleck der Sonde (unverändert gelassen):renderer.texture.bindSource(source, 0) kehrt sofort zurück, wenn Pixi die Quelle an Unit 0 schon gebunden glaubt, und aktiviert Unit 0 dann nicht; gl.getTexParameter liest danach die gerade aktive Unit. gpu:"none" kann also auch vom Messgerät kommen. Sollte der Check je wieder fallen: vor dem Lesen renderer.texture.unbind(texture) und dann bindSource, damit wirklich Unit 0 gelesen wird.
Geschlossen als nicht reproduzierbar / Umgebung stillgelegt (User-Entscheidung: kein Code).
## Befund (2026-09-12) – nicht reproduzierbar, Umgebung ist weg
**Alle drei aufbewahrten Fehlschläge stammen vom Remote-Windows-Browser** (`Testinger@192.168.100.150`) am **09.09.** (13:02, 13:43, 22:13). Signatur in allen drei identisch: beide Messungen (nearest *und* linear) liefern dieselben verwaschenen Pixel `#c65641 #a67047 #868a4c #66a552 #3cc85a`, Drift 0; der Lauf mit Treiber-Sonde meldet `scaleMode:"nearest", gpu:"none", uploaded:false`.
**Der Remote-Browser war an dem Tag generell flatterhaft:** in 11 von ~40 Remote-Läufen fielen auch unzusammenhängende Checks (Hierarchie-Falten, Node löschen, Doppelklick, Undo, Palette-Drop, Nesting) – jeweils im Nachlauf grün. Der Launcher lief headless mit `--ignore-gpu-blocklist` auf der Windows-Karte.
**Lokal (chromium, erzwungene GPU, seit 11.09. desynchronized WebGL-Kontext): 0 Fehlschläge in allen ~50 vollen Läufen seit dem 10.09.**, jedes Mal `gpu:"nearest", uploaded:true`. Die Remote-Maschine steht auf absehbare Zeit nicht zur Verfügung.
**Geprüft und ausgeschlossen (Pixi 8.20.1):**
- Listener-Verlust nach Textur-GC: `GCManagedHash.remove` setzt den Eintrag auf `null`, ein erneutes `add` hängt `styleChange` wieder an.
- Ein Tausch oder `destroy` der Textur-Quelle im eigenen Code: gibt es nicht; Sprite-Views, Texture-Tab und Picker teilen sich die eine `TextureLibrary`-Map.
- Bereits früher: Filterpfad selbst, 30 Wechsel in einer Sitzung, Kontextverlust.
**Was die Signatur sagt und was nicht:** `uploaded:false` heißt, die Bibliotheks-Textur lag zum Messzeitpunkt nicht auf der GPU, während der Schirm ein (linear gefiltertes) Bild zeigte. Für eine Textur, die jedes Frame gezeichnet wird, passt das nicht zusammen – ohne die Maschine nicht erklärbar.
**Blinder Fleck der Sonde (unverändert gelassen):** `renderer.texture.bindSource(source, 0)` kehrt sofort zurück, wenn Pixi die Quelle an Unit 0 schon gebunden glaubt, und aktiviert Unit 0 dann *nicht*; `gl.getTexParameter` liest danach die gerade aktive Unit. `gpu:"none"` kann also auch vom Messgerät kommen. Sollte der Check je wieder fallen: vor dem Lesen `renderer.texture.unbind(texture)` und dann `bindSource`, damit wirklich Unit 0 gelesen wird.
Geschlossen als **nicht reproduzierbar / Umgebung stillgelegt** (User-Entscheidung: kein Code).
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
e2e-Check
pixel-art filteringin12-texturesfällt gelegentlich, im Nachlauf grün.Stand: fällt mit
gpu:"none", uploaded:false. Ausgeschlossen: der Filterpfad selbst, 30 Wechsel in einer Sitzung, Kontextverlust. Verdacht: Timing/Umgebung.Messgerät:
__gm.textureFilter(datei)(Modellwert und Treiberzustand).Übernommen aus
todo-notes/flaky-pixel-art-filtering.mdbeim Umzug auf das Issue-System (2026-09-12).bf41919— Add todo notes for the next round of features, gaps and upkeepBefund (2026-09-12) – nicht reproduzierbar, Umgebung ist weg
Alle drei aufbewahrten Fehlschläge stammen vom Remote-Windows-Browser (
Testinger@192.168.100.150) am 09.09. (13:02, 13:43, 22:13). Signatur in allen drei identisch: beide Messungen (nearest und linear) liefern dieselben verwaschenen Pixel#c65641 #a67047 #868a4c #66a552 #3cc85a, Drift 0; der Lauf mit Treiber-Sonde meldetscaleMode:"nearest", gpu:"none", uploaded:false.Der Remote-Browser war an dem Tag generell flatterhaft: in 11 von ~40 Remote-Läufen fielen auch unzusammenhängende Checks (Hierarchie-Falten, Node löschen, Doppelklick, Undo, Palette-Drop, Nesting) – jeweils im Nachlauf grün. Der Launcher lief headless mit
--ignore-gpu-blocklistauf der Windows-Karte.Lokal (chromium, erzwungene GPU, seit 11.09. desynchronized WebGL-Kontext): 0 Fehlschläge in allen ~50 vollen Läufen seit dem 10.09., jedes Mal
gpu:"nearest", uploaded:true. Die Remote-Maschine steht auf absehbare Zeit nicht zur Verfügung.Geprüft und ausgeschlossen (Pixi 8.20.1):
GCManagedHash.removesetzt den Eintrag aufnull, ein erneutesaddhängtstyleChangewieder an.destroyder Textur-Quelle im eigenen Code: gibt es nicht; Sprite-Views, Texture-Tab und Picker teilen sich die eineTextureLibrary-Map.Was die Signatur sagt und was nicht:
uploaded:falseheißt, die Bibliotheks-Textur lag zum Messzeitpunkt nicht auf der GPU, während der Schirm ein (linear gefiltertes) Bild zeigte. Für eine Textur, die jedes Frame gezeichnet wird, passt das nicht zusammen – ohne die Maschine nicht erklärbar.Blinder Fleck der Sonde (unverändert gelassen):
renderer.texture.bindSource(source, 0)kehrt sofort zurück, wenn Pixi die Quelle an Unit 0 schon gebunden glaubt, und aktiviert Unit 0 dann nicht;gl.getTexParameterliest danach die gerade aktive Unit.gpu:"none"kann also auch vom Messgerät kommen. Sollte der Check je wieder fallen: vor dem Lesenrenderer.texture.unbind(texture)und dannbindSource, damit wirklich Unit 0 gelesen wird.Geschlossen als nicht reproduzierbar / Umgebung stillgelegt (User-Entscheidung: kein Code).