brian/Journal
Watch
1
0
Fork
You've already forked Journal
 0
Code Issues Pull requests Projects Releases 15 Packages 1 Wiki Activity Actions

test #13

Merged
brian merged 2 commits from test into main 2026-08-07 22:35:37 +00:00
Conversation 0 Commits 2 Files changed 17 +2687 -653
brian commented 2026-08-07 22:35:32 +00:00
Owner
Copy link
No description provided. 
Extracts everything that isn't rendering out of InkView into InkEngine —
page state, transform, undo, palm rejection, pinch, erase, text placement —
so a second surface can drive it. InkView keeps its committed-bitmap
rendering; LowLatencyInkView wraps a LowLatencyCanvasView and puts wet ink
straight into the front buffer. DayScreen picks one per page.

The library's two callbacks do not mean what their names suggest, and both
of the earlier attempts at this were lost to guessing:

  - onRedrawRequested fires only when the surface is created or resized. It
    is not the page-repaint hook and there is no way to ask for one, so a
    repaint after an erase or a pinch is done from inside
    onDrawFrontBufferedLayer against our own dirty flag, in SRC mode — the
    buffer keeps its contents, and blending would leave erased ink behind.
  - commit() snapshots the front buffer into the view's bitmap rather than
    re-rendering. So the buffer has to hold the whole page, not just the
    stroke, or committing throws the page away.
  - A render asked for before the surface exists is dropped with no
    callback and nothing that would ask again. Retried on a timer.

Wet ink is handed over incrementally, with the joining sample included:
repainting the whole stroke each pass gives back the latency this is for,
and omitting the join draws it dashed. WetSegmentTest covers both, and the
existing 46 ink tests ran unchanged throughout as the safety net.

Off by default (Settings → Ink, beside the probe). A front-buffered layer
can be refused by a vendor's gralloc with nothing thrown, and ink then goes
somewhere that never reaches the screen; a journal that quietly eats
handwriting is worse than one that draws a frame late. If renders are asked
for and none complete within a second, the surface clears the preference
and hands back to the plain view.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
A month grid shows one picture per day. Getting those meant waiting for the
notebook's whole attachment list and then pulling a full-size photo per
day — megabytes each, for a cell sixty pixels across — with the grid blank
throughout, and blank again next time, because an image cache sized as a
fraction of the disk evicts photos quickly.

DayPhotoCache makes the thumbnail once and keeps it: a 256px JPEG in
filesDir/thumbs, one row per day in day_photos. The calendar draws from
that before asking the server, so a month already seen appears complete
with no request at all, offline included.

Scoped to the visible month — a notebook can hold years, and filling all of
them on first open would be worse than the slowness this replaces — and
each picture is shown as it lands rather than after the last download, so a
month seen for the first time fills in progressively.

Keyed by attachment id, so a replaced photo is noticed, the old file is
deleted, and the new one lands at a path no image cache can serve the
previous bitmap from. A failed fetch changes nothing: going offline
mid-month leaves the thumbnails that were already there. Signing out
deletes the lot.

Decoded with inSampleSize rather than in full, or a month of holiday photos
would be tens of megabytes of bitmap on the way to a stamp-sized cell.

The first view of a month still downloads a photo per new day; fixing that
needs a thumbnail endpoint, and an image library the backend doesn't have.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
brian merged commit dabf4601f3 into main 2026-08-07 22:35:37 +00:00
Sign in to join this conversation.
Reviewers
No reviewers
Labels
Clear labels
No items
No labels
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
brian/Journal!13
No description provided.