UnigramDev/Unigram/develop • b162d28 • 1 files, +0/-3
Drop the packaging project's pre-build event

It only ever ran inside Visual Studio. Under MSBuild ProjectDir and
ConfigurationName are empty, so it expanded to

UpdateManifest.ps1 -path "\" -config "" -mode "SideloadOnly"

which PowerShell read as one escaped argument, Resolve-Path rejected, and git
answered "cannot change to 'rev-list'". The script's TryParse guard then exited
without touching anything - silently, and with the build reporting success. The
package inherited whatever version the manifest already carried, which is how
two different builds ended up stamped 12.10.0.13894 and one overwrote the other.

Build.ps1 already calls UpdateManifest.ps1 itself before invoking msbuild, which
is the call that works, so this was a duplicate of it that could only fail.

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

UnigramDev/Unigram/develop • 6d23cf4 • 1 files, +39/-3
Pin down why the call window does not animate

It is the Windows SDK XAML projection, not the app. A CompositionTarget.Rendering
handler subscribed on a secondary view runs on the main view's thread: measured in
a throwaway app (subscribed on 5, ran on 4) and matched by the app's own log, which
pairs a presenter whose bitmaps were built on thread 23 with a DrawFrame on thread
4.

Microsoft.Windows.UI.Xaml.dll caches the statics in a plain static field and
carries no ThreadStatic or ThreadLocal anywhere, so the first view to touch
CompositionTarget owns it for the process and everyone else's add_Rendering
registers against that view's core. No CsWinRT property covers it.

That also explains what looked contradictory: the call's blob waves animate because
Composition objects are agile, while lottie and video die on WriteableBitmap, which
is not - RPC_E_WRONG_THREAD, swallowed by the XAML handler.

Three options written down, smallest first. Nothing changed in the app yet.

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

UnigramDev/Unigram/develop • 87a294a • 2 files, +34/-12
1.56x in the app, and the Utf8JsonReader set stops being built

Two startups differing only in TdParsers: 87.4 MB/s through Utf8JsonReader
against 136.4 through TdJsonReader. The corpus says 2.4x for the same two
parsers on the same toolchain, so the app sees about two thirds of it.

The gap is everything the change does not touch. Solving for it puts the
reader-dependent work at 2.9 ms/MB and the shared part at 4.4 - 60% - which is
building the object graph and, mostly, a GC that promotes objects the app goes
on to hold, where a benchmark loop sweeps them at gen0. A corpus ratio is an
upper bound on what a parser change buys in situ.

Worth ~105 ms of TDLib-thread time on a startup that size, on top of the ~85 ms
the file-check deferral took off it.

So TdParsers goes to Pointer: 44,508 generated lines and ~500 hand-written ones
stop being compiled, and the app carries one parser. Reader walks it back in
one word - nothing was deleted, and Both is still there for the benchmark.

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

#unigram