UnigramDev/Unigram/develop • 2414af2 • 5 files, +118/-28 Publish arriving media a whole album at a t

UnigramDev/Unigram/develop • 2414af2 • 5 files, +118/-28
Publish arriving media a whole album at a time

An album was filling up a batch at a time, so it visibly reflowed as each photo
landed. Results are now buffered by their position in the source and only the
longest settled run is published, truncated to a multiple of the album size
while media are still arriving.

It is every complete album available rather than one per pass, so a drop that
types quickly still lands in a single flush and only a genuinely slow one
degrades into album-sized steps. The final flush publishes the tail, including
a part-filled last album. A drop that asked for files rather than media is not
chunked at all, since file rows do not reflow.

Publishing a run rather than a batch also fixes the order. Flush sorted within
a batch but appended batches as they arrived, so a slot that resolved late
landed after everything behind it -- the picked order was wrong across batches,
and album membership with it. A run is required anyway: album membership is
positional, so a slot that has not settled could still turn out to be a
document and split the album behind it.

ProbeAsync therefore reports every index, passing null for a file it could not
type. A failure used to be silent, which would leave a permanent hole that the
run could never get past.

The album limit is now StorageAlbum.MAX_ITEMS instead of a bare 9 in the two
places the popup groups by.

Trade-off: a slow file holds back everything behind it, where those items used
to appear without it, out of order. The popup and its title still appear
immediately, which was the complaint this all started from.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

UnigramDev/Unigram/develop • c7d8a18 • 2 files, +98/-38
Stop UpdatePanel redoing settled work on every pass

The container walk rebuilt a whole effect graph per media item per pass: a
GaussianBlurEffect, an effect factory, a brush, a backdrop brush and a sprite
visual. Compiling the graph is the expensive half and it never varies, so the
factory is now built once and every spoiler brush comes from it. Per popup
instance rather than static, since the compositor belongs to the window.

The same walk also reassigned a fresh ParticlesImageSource and re-set or
re-nulled the backdrop child visual on every item every time, whether or not
anything had changed. Both now only touch the tree when the state they
represent actually flipped.

And the walk itself ran once per caller. The album panels each raise Loading
and every arriving batch raises this again, so the calls come in bursts and
each was waiting on the same layout pass to do the same work. A call that finds
one already waiting now returns: the walk reads live state rather than anything
captured when it was scheduled, so the one in flight already covers whatever
the callers behind it changed. The flag clears before the walk, so a call that
arrives during one still gets its own.

Two findings from the review doc turned out to be wrong and are corrected
there rather than acted on. UpdateLayoutAsync does not force a layout pass, it
waits for the next one. And the regenerated StorageDocument wrappers did not
churn the diff, because the fallback comparison matches on path and type -- so
caching them would have bought a bug risk in two invalidation sites for no
measurable gain.

Also adds a task for reordering media inside an album, which nothing currently
allows: the ListView reorders rows, but the media within one are Buttons in a
bare Grid with no items control involved.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

#unigram