ｙ

docs/VIEWER_FIXES.md

@@ -33,3 +33,29 @@
 追加した中間倍率（Seahorse、span=1e-6）と旧Deep専用の黒領域は、それぞれ12サンプルの分類と脱出反復数が独立BigInt計算に一致した。一方、連続色付け用smooth値の差は最大約0.0367反復分／0.0516反復分だった。両ケースではsmoothのULP精度を保証せず、偏差をテスト出力に記録する。高速Seahorseと実軸の8 ULP以内という検査は維持している。旧正確モードと同じ色の数値精度を維持したという主張ではない。
 
 最終版でCPU回帰と実GPUの `all` が通過した。6描画ケースの数値失敗は0。1100×720の実画面でも自動色相変化による色の変化、描画完了直後の「2.32 s」、描画方式の選択肢がないことを確認した。検証用Edgeと専用プロファイルは終了・削除済みで、残存Edgeプロセスは0だった。
+
+## 2026-09-07：配色整理と彩色変更の応答
+
+「桃翠」「ネオン」「紅碧」「深海」をUIと色シェーダーから削除し、「ピンクと黒」（ID 19）を追加した。残る配色のIDは維持し、削除した配色を指定する旧URLは「昼夜」に戻す。
+
+通常の彩色変更ハンドラー自体は数値再計算を起動していなかった。しかし計算中の彩色変更は、自動色相変化を有効にしたときだけ使える公開済みデータに依存し、無効時は計算終了まで待たされていた。計算中にも公開済みデータを保持することで、通常の彩色変更・色相位置・色周期も数値計算とは独立して反映する。連続入力は描画フレームごとに最新値へまとめる。
+
+この変更に伴い、上記の追加領域は自動色相変化中に加えて数値計算中にも保持する。完成後、自動色相変化が無効で保留中の彩色もなければ解放する。追加容量は12 byte/画素＋32 byteで変わらない。
+
+色だけが違うURLへの移動・表示履歴の復元は再彩色だけにし、描画サイズが変わらないresize通知からの数値再計算も抑止した。計算用シェーダーは変更していない。
+
+`node tests/browser_smoke.mjs 9333 palette` にて、320×240の彩色反映は完成後約19.1 ms、実際の数値補修中約9.3 msだった（各1回の測定、機器や負荷により変動）。数値投入回数・生成ID・計算結果が彩色変更で変わらず、計算中の彩色変更でも最終数値ハッシュが一致し、PNGの画素不一致が0であることを確認した。
+
+CPU回帰と実GPUの `palette`・`ui` が通過。1100×720の実画面で新配色を確認し、削除済み配色のURLを開いても再計算せず「昼夜」へ戻ることも確認した。
+
+その後「ピンクと黒」の暗部をプラム色へ調整。深いプラムからモーヴ、くすんだローズ、淡いピンクへ移る5色のグラデーションとし、この配色の未脱出・内点表示も紫がかった暗色にした。数値判定は変更せず、CPU回帰と1100×720の実GPU表示で確認した。
+
+## 色相変化中のパン
+
+彩色が遅いと、新しい色相変更が待機中に届き続け、再彩色ループが `recoloring=true` のままパン後の数値計算開始を阻害していた。1回の彩色で必ず処理を返し、視点更新があるときは数値計算を優先するようにした。
+
+ドラッグ中は再投影による移動表示を優先し、自動色相の描画更新は操作終了後に再開する。数値計算中の自動彩色は最大10回/秒、静止中は従来の最大20回/秒。公開済みデータを使う彩色も未完了のGPU処理を1件までに制限し、遅いGPUへ処理を積み続けない。色相変化のオン状態は維持する。
+
+320×240で同一のパンを実マウスイベントから実行した結果、完了までオフ約343 ms、オン約352 msだった。彩色へ意図的に100 msの遅延を加えた検査でも約677 msで完了し、3条件の数値ハッシュが一致した。各1回の測定であり、機器・座標に依存する。再現検査は `node tests/browser_smoke.mjs 9333 pan`。
+
+プラムの暗部も再調整し、未脱出・内点は `#0e0a13`、グラデーションの最暗部は `#140e1a` とした。ローズと淡いピンクの色は維持する。