| Commit message (Collapse) | Author | Age | Files | Lines | |
|---|---|---|---|---|---|
| * | A flick through the feed no longer drags background work through the middle ↵ | Adam Soltys | 23 hours | 1 | -3/+3 |
| | | | | | | | | of it. "When I flick to scroll, it's not getting up to speed very quickly, and clicking around in the app feels a bit sluggish at times" (Adam, 2026-11-07). Measured on his Pixel 9 in the installed PWA: idle is quiet (0.16 s of script in 10 s), but three real flicks through Following spent 1.7 s of 9 on the main thread, frames up to 200 ms, and the work was the avatar thumbnailer finishing faces as they scrolled in: a synchronous canvas.toDataURL WebP encode per face (229 ms), the profile cache JSON.stringified twice per half-second flush (once just to measure it, up to ~2 MB with thumbnails), and a whole-page repaint per finished face that changes nothing on screen (feed rows keep the face they were admitted with). Now: the crop, resize and encode happen off the main thread (createImageBitmap with resizeWidth/Height, OffscreenCanvas.convertToBlob, FileReader), with the old canvas path as the fallback; a finished face is recorded once the page settles; scheduleRepaint holds while a finger is down or the page scrolled in the last 200 ms (at most 1.5 s), and the profile flush likewise (at most 5 s, forced on an account switch) and sizes the blob by summing rows instead of stringifying it. Tests: the create flow's heads-up / passphrase / check steps from earlier today broke every test that made a wallet by waiting for the words and clicking "Skip verification"; tools/puppeteer.js exports seedWords() and skipSeedCheck() and the 96 tests use them. room-faces and avatar-profile fail the same way on 8858591 (row.hover, scrollIntoView), before today's changes Co-Authored-By: Claude Opus 5.5 <[email protected]> Claude-Session: https://claude.ai/code/session_01VMan6Ts5Tktega8VbLg31q | ||||
| * | Videos: a tap on the picture goes full screen. The corner full-screen button ↵ | Adam Soltys | 2026-10-10 | 1 | -1/+1 |
| | | | | | | | | is a reach on a phone, so a tap anywhere on a feed clip — outside the player's own big play button and control bar, judged from the tap's position since those live inside the video element — now goes full screen (a wide clip asks for landscape). Full screen, a tap pauses a playing clip, and a tap on a paused one (again outside its play button and controls) comes back out. A video's taps no longer reach the post either: a tap on the player's controls used to open the thread, which in full screen took the player out from under the reader. tools/video-tap-test.js Co-Authored-By: Claude Opus 5.5 <[email protected]> Claude-Session: https://claude.ai/code/session_01Vps2H27rhbG9ZqseGfMrc3 | ||||
| * | Feed: a slow picture keeps loading in place instead of turning into a link. ↵ | Adam Soltys | 2026-10-10 | 1 | -0/+73 |
| A feed row waits up to 8 s for its pictures, then freezes as it is; a picture still downloading at that moment (Juraj's 3.5 MB PNG from blossom.primal.net, on a phone) was frozen as its bare URL, and only showed when the post was opened. Now a picture that was merely slow is drawn in a fixed 4:3 box (fitted inside, so nothing moves when it lands) and keeps loading; only a picture that refused to load (an error, not a timeout — mediaFailed) is still a link. tools/slow-image-test.js (a picture served after 11 s; on the old code it was a link). Co-Authored-By: Claude Opus 5.5 <[email protected]> Claude-Session: https://claude.ai/code/session_01Vps2H27rhbG9ZqseGfMrc3 | |||||
