UnigramDev/Unigram/composer-typing-performance • b4cfc42 • 4 files, +139/-49
Grow SendFilesPopup albums instead of rebuilding them

CompareItems compared album contents, so an album that gained a photo was a
different item and the diff removed and re-inserted it. That recycled the
container, and the recycle handler releases the album's thumbnails on the way
out -- so every batch of arriving photos re-decoded every thumbnail the album
already had. The remeasure was the visible symptom; this was the cost.

ChatDiffHandler shows the intended contract: CompareItems is identity and
UpdateItem carries the new content across. StorageAlbum now has an Ordinal, its
position among the albums of a view, and that is what CompareItems compares. An
album that gains a photo is the same album with new contents, and its container
survives.

UpdateItem moves the new media onto the retained instance and refreshes the
realized panel. Before it only invalidated layout, which meant that whenever it
did fire the panel went on rendering the old contents -- latent, since the old
CompareItems almost never let it fire.

StorageAlbumPanel.UpdateMessage reuses its children rather than clearing them
and allocating a Button per item with a fresh Click subscription. Growth only
appends now, and a surviving item keeps the thumbnail it already had, because
changing Button.Content updates the template root's DataContext instead of
rebuilding it.

Remove_Click invalidates the removed item's thumbnail, since a container
recycling underneath it no longer does.

Also restores the width and height diagnostic. The constructor's Logger.Info
line names each item's dimensions, which is what album layout bugs get
diagnosed from, and the drop path had reduced it to a count because nothing is
typed that early. It now logs the pending count there and logs the dimensions
again once everything has landed.

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

UnigramDev/Unigram/composer-typing-performance • 411fbcd • 5 files, +15/-6
Stop leading text inputs with the packaged emoji font

EmojiTextThemeFontFamily was built emoji-first, so every text input resolved
against ms-appx:///Assets/Emoji/*.ttf before falling back to the text font. The
editor resolves the font once per run and breaks runs at every space, so that
cost about a millisecond per word: pasting 17,000 characters into the composer
froze the UI for 2.7 seconds. Measured identical through SetText and through
RichEdit's own paste, and identical for one line or for hundreds, so it is the
font resolution rather than the insertion.

Leading with the text font instead costs the emojis whose base character it
already covers - keycaps, the copyright and trademark signs and so on -
rendering as plain glyphs. That is confined to input controls: message bubbles
render from XamlAutoFontFamily, which is untouched, so what gets sent and what
gets displayed are both unaffected.

Only three styles used the resource, all of them text input, and four further
inputs were leading with ContentControlThemeFontFamily, which is emoji-first
too and so was just as slow. They all take EmojiTextThemeFontFamily now.

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

#unigram