[1.0 Review] rendering / window / font の config と platform 例外の凍結 #7
Labels
No labels
priority/P0
priority/P1
priority/P2
release/v0.1.0
status/blocked
status/planned
type/bug
type/design
type/test-gap
type/tracker
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set
Reference
natsukium/felis#7
Loading…
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
背景
felis の rendering は daemon が
RowDelta(row 粒度の damage)と画像配置を送り、client がfelis-render-wgpuで毎フレーム全グリッドを再描画する。explanation/rendering/pipeline.mdに cell pass(bg→fg→decoration→image の4 pipeline)+ optional post-process(shader.post)が仕様化。フォントはfelis-shaping(swash)でfont.sizeは logical px。現状の問題 / 凍結前に決めるべき点
1.
window.opacityとwindow.backdropの結合opacityは background opacity(kittybackground_opacityモデル)で、明示的 bg を持つ cell は不透明のまま。OS compositor が合成。backdropは OS-native material(none/blur/acrylic/mica/tabbed)で、各値が特定 OS にのみ有効。現行:
blurはopacity < 1.0でないと window 背面に隠れて無効、Windows material はopacityによらず title bar に効く(body は wgpu DX12 swapchain が opaque のため常に不透明)。backlog.mdに「Windows body transparency は wgpu のCreateSwapChainForHwndがOpaqueのみのため不可」と明記。問い: 1.0 で
opacityとbackdropを独立したキーとして凍結するか、将来の Linux compositor blur 対応でbackdropに Linux 値が追加された時に値集合が OS ごとに分岐し続けることを許容するか。代替:window.transparency = {opacity, backdrop}のようにまとめる。2.
shader.postの契約shader.post = {builtin="trail"} | {file="..."}で、WGSL のfs_postentry point と uniform 契約(reference/shaders.md)が append-only で versioned。shader.animate = "never" | "focused"で continuous redraw を制御。postが単一値(1つの post-process pass)。将来複数 pass(blur→trail のチェーン)を許すならpost = [{...}, {...}]の配列に破壊的変更が必要。今しか配列化できない。animate = "focused"は idle CPU を犠牲にする opt-in。"always"(unfocused でも回す)を意図的に持たない。1.0 でこの「unfocused では回さない」制約を凍結するか。3. font size の単位と範囲
font.size = 14.0は logical px(window scale を掛ける前の値)で、4.0..=72.0に clamp、非正・非有限は built-in default に fallback。MIN_FONT_SIZE_LOGICAL_PX/MAX_FONT_SIZE_LOGICAL_PXがfelis-client-coreに定数。Ctrl+Wheel/font_sizeaction でも同じ band。_logical_pxと_physical_pxの命名分離は DPI 境界での bug を防ぐ意図。1.0 でこの命名と clamp 範囲を凍結するか、将来的にfont.size = "14pt"のような単位付き文字列を許すか。4.
font.fallbackの auto-discover空配列時に CJK 1 face + symbol 全 face + emoji 1 face + nerd 1 face を auto-discover。非空なら宣言順に append し auto-discover は走らない。
family必須、features省略でfont.featuresを継承。auto-discover が暗黙に大量の font を mmap する(Apple Color Emoji 183MiB 等)点は
explanation/rendering/text-shaping.mdに記載。1.0 で auto-discover の対象集合(現行の4グループ)を凍結するか、将来的にユーザがグループごとに on/off できるfont.fallback.autoのような opt-out を追加する余地を残すか。5. damage tracking と render-on-dirty
Daemon が row 粒度で damage を追い、client は redraw flag で全グリッドを再描画(client-side damage なし)。
explanation/rendering/damage-tracking.mdに「underdraw なし」が仕様。felis-gridのScreenBuffervsGridの seam もこのためにある。1.0 で「client は damage を読まない」ことを凍結するか、将来 client-side damage 消費者(例: 部分再描画で省電力)が現れた時の Revisit trigger を
architecture/overview.mdに記録するか。6. platform 均一性 vs 例外
explanation/non-goals.mdで「macOS/Linux/Windows で均一に実装できない機能は省略」が原則だが、window.backdropと ConPTY のt=f/t/s制限は例外として carve-out。1.0 でこの「例外は shim であり gated feature ではない」線引きをより厳密にし、新しい OS 依存機能の追加基準をnon-goals.mdに明記すべき。提案
window.opacity/backdrop/shader.post/font.*の各キーについて、1.0 での凍結値集合をreference/config.mdに「1.0 凍結」ラベル付きで明記し、将来の追加が additive(新backdrop値、新shader.builtin)であることをcontrol-surfaces.mdの lenient parsing 契約と紐づけ。shader.postを将来配列化する可能性があるなら、今のうちにpost = {builtin=...}をpost = [{builtin=...}]に破壊的変更するか、現行単一値を 1.0 として凍結し、将来はpost_listのような別キーで拡張する方針を決める。t=f/t/sはENOTSUP)をreference/protocols/support-matrix.mdとreference/workspace.mdの Build matrix に 1.0 の既知制限として再掲。判定基準
config.tomlのwindow/shader/font節だけを見て、どの値が live reload でどれが要 relaunch か、どの値がどの OS で効くかが推測できること。felis-config.schema.jsonが、将来の minor 追加をadditionalPropertiesnon-strict で許容しつつ、typo を editor 上で検出できること。cc @natsukium
Superseded by the concrete unit rename in #28. The later review retained the existing rendering/window architecture and platform boundary recorded in #12; other speculative redesign questions are not v0.1.0 work.