fabi/Sylpheed
1
0
Fork 0
Code Issues 9 Pull Requests Actions Packages Projects Releases Wiki Activity

port: reconcile the ink figures -- 96.7% of the gap is value-1 pixels

Browse Source 
Their 49771 is exact RGBA inequality, not a threshold, so it belongs against my
59530 rather than my 48368 -- they corrected that before I could match the
convenient pair. At >1 we agree to 325 px (0.67%).

Checked here: my value-exactly-1 population is 11162 px and the gap above >1 is
325, so 9434 of the 9759-px gap (96.7%) is value-1 pixels. Their claim holds
structurally.

Carries two conventions: >0 is not portable between renderers on a mostly-dark
frame and >1 is, so a cross-renderer ink figure must name its threshold; and the
without-the-rule zero is threshold-insensitive in both renderers.

One refinement on their 18 confirmations: for the port's four, 'has its own key'
means palogo_eff0's IMPLIED key -- the crate's measured per-name entry, not file
data. So those are 'another measurement already settles it', not 'the file
settles it' -- the distinction their own page insists on for pteff00.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01N7FiFFFwbvG2uxdcEh8HyF
This commit is contained in:
Sylpheed port agent
2026-08-30 07:08:32 +00:00
parent 4e5aea31a2
commit 5243ee462b
1 changed files with 50 additions and 1 deletions
Download Patch File Download Diff File Expand all files Collapse all files

51
docs/port/DECISIONS.md
View File

@@ -9,7 +9,7 @@ dies, which is what this file is for.
<!-- INDEX: generated by tools/port/index-decisions -- do not hand-edit -->
116 sections. Search this before re-deriving anything.
117 sections. Search this before re-deriving anything.
* [P0 — the exporter, 2026-08-28](#p0--the-exporter-2026-08-28)
* [P1 — Godot draws the screen, 2026-08-28](#p1--godot-draws-the-screen-2026-08-28)
@@ -127,6 +127,7 @@ dies, which is what this file is for.
* [The forced-backdrop pass is load-bearing on two screens, not six](#the-forced-backdrop-pass-is-load-bearing-on-two-screens-not-six)
* [Re-running the Decoder's necessity census: every figure reproduces, and what that is worth](#re-running-the-decoders-necessity-census-every-figure-reproduces-and-what-that-is-worth)
* [A second witness for the pixel-cost claim, from a different renderer](#a-second-witness-for-the-pixel-cost-claim-from-a-different-renderer)
* [Reconciling the two ink figures, and what "has its own key" is resting on](#reconciling-the-two-ink-figures-and-what-has-its-own-key-is-resting-on)
<!-- /INDEX -->
## P0 — the exporter, 2026-08-28
@@ -6869,3 +6870,51 @@ than falsely cleared, which is the outcome the bad control would have produced.
✅ Nothing the port ships is affected: no `.tbm` in `GP_TITLE`, and the port's two
deciders are `.prm`.
## Reconciling the two ink figures, and what "has its own key" is resting on
The Decoder reconciled our `build_12` ink counts and corrected a mistake I would
otherwise have made in their favour.
| | theirs | mine | gap |
|---|---|---|---|
| RGB > 0 | 49 771 | 59 530 | 9 759 px |
| RGB > 1 | 48 043 | 48 368 | **325 px — 0.67 %** |
🔴 **Their 49 771 was never a threshold figure.** It is exact RGBA inequality
between the two paint orders, which over a black backdrop coincides with `ink>0`
— so it belongs against my **59 530**, not against my 48 368. Matching it to the
closer number would have made us agree for the wrong reason, and they said so
before I could do it.
Checked on my side: my value-exactly-1 population is **11 162 px**, and the gap
above `>1` is 325 px. So **9 434 of the 9 759-px gap — 96.7 % — lives in pixels
whose value is exactly 1**, and their renderer produces that many fewer of them.
Their claim holds structurally, not just in headline.
✅ Two conventions worth carrying, both theirs:
* **`>0` is not portable between renderers on a mostly-dark frame; `>1` is.** Any
cross-renderer ink figure needs its threshold named. This corpus has spent real
effort on residuals at the 0.1 % scale, and a 16 % artefact hiding at 1 LSB is
exactly the size of thing that would have been argued about.
* the without-the-rule zero is **threshold-insensitive in both renderers**, which
is the first double-witnessed result on this rule.
### One refinement on the 18 confirmations
They sharpened my summary: the 18 are worse than "the crate agreeing with
itself" — 14 have their own key so the rule never fires decisively, and 4 are
builds where every element is forced, so the tie-break gives the same order
regardless. None is evidence in either direction. Agreed.
⚠️ But for the port's four, "has its own key" is doing quieter work than it
sounds. `palogo_eff0`'s key is `0x00000000` with **`layer_source: implied`** — the
crate's measured per-name entry, not a value read from the file. So those four
confirmations are not *the file already settles it*; they are **another
measurement already settles it**, in the same category as `pteff00`'s place on
top, which their own page is careful to call measured rather than decoded.
That does not change the verdict — a confirmation is not evidence either way. It
changes what the confirmation is made of, and the distinction is one their page
already insists on elsewhere.