Files
Sylpheed/docs
Sylpheed port agent c01580740e port: my pteff10 counter-example failed, H5 closes as additive, and I broke my own allowance
Three things, and the first is the one worth reading.

 MY COUNTER-EXAMPLE FAILED. I reported pteff10 as a possible counter-example to
the  DECODED blend bit. It is not: the oracle measures it ADDITIVE on main_menu
in all three menu sessions, every frame, entry 5 of blend-bit-vs-oracle.txt.

My premise was a stale COVERAGE TABLE of theirs, sitting upstream of its own
correction. I inferred "their log does not cover this element" from a summary and
called it a contradiction with a capture. The lesson is not that their table was
stale -- it is that I treated a summary as the log, having spent three iterations
insisting that other people quote instruments rather than conclusions.

Their explanation made a prediction, so I checked it rather than accepting it:
if additive and alpha-over nearly coincide on a dim glow, why did my score move
20 %? Diffing the two renders, where pteff10's blend is the only change:

  identical        373 588 px (40.5 %)
  differing > 3    330 794 px (35.9 %)
  MAX difference   32 levels        pixels >= 60:  0

Their explanation holds and my scepticism does not. Nothing moves more than
32/255. What moved the RMSE is AREA.

📌 And that generalises past this row: raw-rmse is AREA-WEIGHTED, so a shallow
change over a third of the frame moves it far more than a deep change over a few
hundred pixels, and the number alone cannot say which you have. 10.88 -> 13.02
reads like a serious regression and is invisible to an eye. Any verify-capture
row that moves should be asked "broad or deep?" first; it costs one histogram.

I did NOT take their suggestion to exclude the element from the metric. The
reason to exclude -- "the metric cannot distinguish these" -- is now measured to
be false; it distinguishes them fine and weights them by area. Excluding would
remove the only signal that would fire if the bit were wrong elsewhere.

 H5 CLOSES, as a side effect. pgloading_loop5 -- the element I had localised all
951 differing pixels to -- carries blend_additive, and ui_layout.rs has no
additive path, so the reference cannot reproduce that draw by construction.
build_00/build_01 agreed only because they never draw it; with the decoded field
they gained loop1/loop4 additive and now differ too, as predicted.

🟢 The strongest corroboration of the decoded field came unfitted, from the rows I
was not looking at. EN/JP twins were 4.1x and 7.8x apart under the name-keyed map
and are now 1.1 % and 1.3 % apart (main_menu 7.26 vs 7.34, extras 6.98 vs 7.07).
A disc-wide field predicts locale twins render identically; a screen-name map
cannot. That prediction was not available to me before the swap.

🔴 AND I BROKE MY OWN ALLOWANCE, silently, one iteration after building it.
check-all's verify-screen allowance derived from authored/rendering.json's
additive_elements -- the key I deleted last commit -- so it evaluated to EMPTY and
would have failed six rows for no reason anyone could read off the output. Caught
by going to look, not by the check. A derived allowance is only as durable as the
thing it derives from, and I pointed this one at a file I then emptied.

It now derives from the EXPORT. ⚠️ That is LOOSER and the cost is stated: 12 of
16 screens qualify and verify-screen goes fully green. Measured after the swap
the two sets line up exactly -- all 10 differing screens have a drawn additive
element, all 6 agreeing screens have none -- but a screen differing for some
OTHER reason would now be excused. 📌 The real fix is not here: verify-screen
compares two renderers and one cannot express a blend the disc declares. Giving
ui_layout.rs an additive path would make it meaningful again. PROPOSED, not done
-- their crate, and their refutation of additive predates the measurement that
overturned it.

Not settled: finding 3, which now has no surviving named cause at all -- the
Decoder is taking the clock origin, on the grounds that every measurement either
of us has made is a DIFFERENCE and a difference cannot detect a common offset.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_018AHUQvXGyNcKonSEWsgWcX
2026-09-01 18:59:11 +00:00
..