Der E2E-Check pixel-art filtering keeps the border between two quadrants hard faellt sporadisch um — am 2026-09-09 zweimal in vier Laeufen, jeweils ohne dass eine Aenderung
Texturen beruehrt haette.
rot: ["#c65641","#a67047","#868a4c","#66a552","#3cc85a"] — weicher Verlauf, also linear
Erledigt: der Folge-Check deckt nichts mehr zu
Der zweite Check (switching the filter back to smooth …) verglich nur soft.some(c => !pure(c))
und meldete damit auch dann gruen, wenn beide Filter denselben Verlauf zeigten — ein haengender
Wechsel liess genau einen Check fallen, der zweite verdeckte ihn.
Er verlangt jetzt zusaetzlich, dass sich das Bild gegenueber nearest messbar geaendert hat
(Summe der Farbabstaende ueber die fuenf Punkte > 150). An den oben aufgezeichneten Reihen
gerechnet: echter Wechsel 425, haengender 0 — und 30 selbst dann, wenn jeder Kanal um zwei
danebenlaege. Beide Checks legen ausserdem __gm.textureFilter(datei) in ihren Fehlertext.
Das Messgeraet
__gm.textureFilter(datei) liest beides: was das Modell will (scaleMode) und was der Treiber
tatsaechlich weiss (gl.getTexParameter an der hochgeladenen Textur). Ein FAIL beantwortet damit
von selbst, was bisher Deutungssache war:
Messung
Bedeutung
scaleMode linear, Bild weich
das Modell hat nie umgeschaltet
scaleMode nearest, gpu linear
der Wechsel erreichte den Sampler nicht — Produktfehler
beide nearest, Bild trotzdem weich
der Test misst falsch
Es bindet die Source ueber renderer.texture.bindSource statt per rohem bindTexture — sonst
verfaelscht die Messung Pixis Vorstellung davon, was gebunden ist, und stiftet selbst Flakiness.
Offen: die Ursache
Vier Hypothesen sind gemessen und widerlegt — nicht erneut probieren:
Dass in ueber 60 gezielten Versuchen nichts faellt, waehrend der echte Lauf in ein bis zwei von
vier Laeufen umfaellt, ist der eigentliche Widerspruch.
Naechste Spur bleibt die Umgebung: Chrome meldet beim Start auf der Windows-Maschine GPU process exited unexpectedly: exit_code=34. Wie oft das passiert, ist allerdings unbekannt — harness.mjs gibt die Browser-stderr nur bei einer Exception oder bei RUN DIED aus, in gruenen
Laeufen also nie. Solange das so ist, laesst sich gar nicht messen, ob der Absturz mit dem
Fehlschlag korreliert. Wer hier weitermacht, protokolliert die stderr zuerst bei jedem Lauf.
Die Sonden dazu waren Wegwerfware und sind geloescht. Wer weitermacht, baut sie neu — beide
waren duenn: die eine fuhr den echten Modul-Vorlauf und danach eine Messschleife aus
Filterwechsel + __gm.textureFilter, die andere erzwang ueber WEBGL_lose_context einen
Kontextverlust und mass danach dasselbe.
Warum diese Notiz trotz offener Ursache in done/ liegt
Abgelegt am 2026-09-09 auf Anweisung. Erledigt ist der Testmangel, den die Notiz beschrieb,
plus das Messgeraet — die Ursache der Sporadik nicht. Faellt der Check wieder um, ist das hier
der Stand: vier widerlegte Hypothesen und die einzige offene Spur (stderr zuerst protokollieren).
Übernommen aus todo-notes/done/flaky-pixel-art-filter.md beim Umzug auf das Issue-System (2026-09-12).
Angelegt: 2026-09-09 · d7c8d3e — Measure a deviation against the base, not the innermost template
Abgeschlossen: 2026-09-09 · 75be133 — Make the smooth-filter check unable to cover for the hard one
Gemeldet von: Claude (Assistent)
Der E2E-Check `pixel-art filtering keeps the border between two quadrants hard` faellt
**sporadisch** um — am 2026-09-09 zweimal in vier Laeufen, jeweils ohne dass eine Aenderung
Texturen beruehrt haette.
- gruen: `["#e63c3c","#e63c3c","#3cc85a","#3cc85a","#3cc85a"]` — harte Kante, `nearest` greift
- rot: `["#c65641","#a67047","#868a4c","#66a552","#3cc85a"]` — weicher Verlauf, also `linear`
## Erledigt: der Folge-Check deckt nichts mehr zu
Der zweite Check (`switching the filter back to smooth …`) verglich nur `soft.some(c => !pure(c))`
und meldete damit auch dann gruen, wenn **beide** Filter denselben Verlauf zeigten — ein haengender
Wechsel liess genau einen Check fallen, der zweite verdeckte ihn.
Er verlangt jetzt zusaetzlich, dass sich das Bild gegenueber `nearest` messbar geaendert hat
(Summe der Farbabstaende ueber die fuenf Punkte > 150). An den oben aufgezeichneten Reihen
gerechnet: echter Wechsel 425, haengender 0 — und 30 selbst dann, wenn jeder Kanal um zwei
danebenlaege. Beide Checks legen ausserdem `__gm.textureFilter(datei)` in ihren Fehlertext.
## Das Messgeraet
`__gm.textureFilter(datei)` liest **beides**: was das Modell will (`scaleMode`) und was der Treiber
tatsaechlich weiss (`gl.getTexParameter` an der hochgeladenen Textur). Ein FAIL beantwortet damit
von selbst, was bisher Deutungssache war:
| Messung | Bedeutung |
|---|---|
| `scaleMode` linear, Bild weich | das Modell hat nie umgeschaltet |
| `scaleMode` nearest, `gpu` linear | der Wechsel erreichte den Sampler nicht — Produktfehler |
| beide nearest, Bild trotzdem weich | der Test misst falsch |
Es bindet die Source ueber `renderer.texture.bindSource` statt per rohem `bindTexture` — sonst
verfaelscht die Messung Pixis Vorstellung davon, was gebunden ist, und stiftet selbst Flakiness.
## Offen: die Ursache
Vier Hypothesen sind gemessen und **widerlegt** — nicht erneut probieren:
| Hypothese | Messung | Ergebnis |
|---|---|---|
| Der Wechsel erreicht den GPU-Sampler nicht | 30 Wechsel, Modell und `gl.getTexParameter` gelesen | 60/60 einig |
| Der Vorlauf der elf Module hinterlaesst etwas | 15 Runden nach echtem Vorlauf | alle gruen |
| Verlorener GPU-Prozess (Chrome meldete `exit_code=34`) | Kontext gezielt verloren und wiederhergestellt | `nearest` ueberlebt beides, auch mit Redraw |
| Genau **ein** Wechsel auf frischer Seite, wie im Test | 12 Runden, je neuer Seed und Seitenaufbau | alle gruen |
Dass in ueber 60 gezielten Versuchen nichts faellt, waehrend der echte Lauf in ein bis zwei von
vier Laeufen umfaellt, ist der eigentliche Widerspruch.
Naechste Spur bleibt die Umgebung: Chrome meldet beim Start auf der Windows-Maschine
`GPU process exited unexpectedly: exit_code=34`. Wie oft das passiert, ist allerdings **unbekannt** —
`harness.mjs` gibt die Browser-stderr nur bei einer Exception oder bei `RUN DIED` aus, in gruenen
Laeufen also nie. Solange das so ist, laesst sich gar nicht messen, ob der Absturz mit dem
Fehlschlag korreliert. Wer hier weitermacht, protokolliert die stderr zuerst bei jedem Lauf.
Die Sonden dazu waren Wegwerfware und sind geloescht. Wer weitermacht, baut sie neu — beide
waren duenn: die eine fuhr den echten Modul-Vorlauf und danach eine Messschleife aus
Filterwechsel + `__gm.textureFilter`, die andere erzwang ueber `WEBGL_lose_context` einen
Kontextverlust und mass danach dasselbe.
## Warum diese Notiz trotz offener Ursache in `done/` liegt
Abgelegt am 2026-09-09 auf Anweisung. **Erledigt ist der Testmangel**, den die Notiz beschrieb,
plus das Messgeraet — die **Ursache der Sporadik nicht**. Faellt der Check wieder um, ist das hier
der Stand: vier widerlegte Hypothesen und die einzige offene Spur (stderr zuerst protokollieren).
---
*Übernommen aus `todo-notes/done/flaky-pixel-art-filter.md` beim Umzug auf das Issue-System (2026-09-12).*
- **Angelegt:** 2026-09-09 · `d7c8d3e` — Measure a deviation against the base, not the innermost template
- **Abgeschlossen:** 2026-09-09 · `75be133` — Make the smooth-filter check unable to cover for the hard one
- **Gemeldet von:** Claude (Assistent)
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.
Der E2E-Check
pixel-art filtering keeps the border between two quadrants hardfaelltsporadisch um — am 2026-09-09 zweimal in vier Laeufen, jeweils ohne dass eine Aenderung
Texturen beruehrt haette.
["#e63c3c","#e63c3c","#3cc85a","#3cc85a","#3cc85a"]— harte Kante,nearestgreift["#c65641","#a67047","#868a4c","#66a552","#3cc85a"]— weicher Verlauf, alsolinearErledigt: der Folge-Check deckt nichts mehr zu
Der zweite Check (
switching the filter back to smooth …) verglich nursoft.some(c => !pure(c))und meldete damit auch dann gruen, wenn beide Filter denselben Verlauf zeigten — ein haengender
Wechsel liess genau einen Check fallen, der zweite verdeckte ihn.
Er verlangt jetzt zusaetzlich, dass sich das Bild gegenueber
nearestmessbar geaendert hat(Summe der Farbabstaende ueber die fuenf Punkte > 150). An den oben aufgezeichneten Reihen
gerechnet: echter Wechsel 425, haengender 0 — und 30 selbst dann, wenn jeder Kanal um zwei
danebenlaege. Beide Checks legen ausserdem
__gm.textureFilter(datei)in ihren Fehlertext.Das Messgeraet
__gm.textureFilter(datei)liest beides: was das Modell will (scaleMode) und was der Treibertatsaechlich weiss (
gl.getTexParameteran der hochgeladenen Textur). Ein FAIL beantwortet damitvon selbst, was bisher Deutungssache war:
scaleModelinear, Bild weichscaleModenearest,gpulinearEs bindet die Source ueber
renderer.texture.bindSourcestatt per rohembindTexture— sonstverfaelscht die Messung Pixis Vorstellung davon, was gebunden ist, und stiftet selbst Flakiness.
Offen: die Ursache
Vier Hypothesen sind gemessen und widerlegt — nicht erneut probieren:
gl.getTexParametergelesenexit_code=34)nearestueberlebt beides, auch mit RedrawDass in ueber 60 gezielten Versuchen nichts faellt, waehrend der echte Lauf in ein bis zwei von
vier Laeufen umfaellt, ist der eigentliche Widerspruch.
Naechste Spur bleibt die Umgebung: Chrome meldet beim Start auf der Windows-Maschine
GPU process exited unexpectedly: exit_code=34. Wie oft das passiert, ist allerdings unbekannt —harness.mjsgibt die Browser-stderr nur bei einer Exception oder beiRUN DIEDaus, in gruenenLaeufen also nie. Solange das so ist, laesst sich gar nicht messen, ob der Absturz mit dem
Fehlschlag korreliert. Wer hier weitermacht, protokolliert die stderr zuerst bei jedem Lauf.
Die Sonden dazu waren Wegwerfware und sind geloescht. Wer weitermacht, baut sie neu — beide
waren duenn: die eine fuhr den echten Modul-Vorlauf und danach eine Messschleife aus
Filterwechsel +
__gm.textureFilter, die andere erzwang ueberWEBGL_lose_contexteinenKontextverlust und mass danach dasselbe.
Warum diese Notiz trotz offener Ursache in
done/liegtAbgelegt am 2026-09-09 auf Anweisung. Erledigt ist der Testmangel, den die Notiz beschrieb,
plus das Messgeraet — die Ursache der Sporadik nicht. Faellt der Check wieder um, ist das hier
der Stand: vier widerlegte Hypothesen und die einzige offene Spur (stderr zuerst protokollieren).
Übernommen aus
todo-notes/done/flaky-pixel-art-filter.mdbeim Umzug auf das Issue-System (2026-09-12).d7c8d3e— Measure a deviation against the base, not the innermost template75be133— Make the smooth-filter check unable to cover for the hard one