UnigramDev/Unigram/develop • 35b04e1 • 1 files, +26/-2
Write down where the calls window stands

Everything else Fela tried works: stickers, animations, WebView2, VLC and
secondary windows. Calls do not - no video, no lottie - and the exceptions behind
it are caught, so ErrorReports stays empty.

Records what the blob waves rule out. They animate, and they run off the same
per-view CompositionTarget.Rendering that AnimatedImage uses, so the frame driver
is not the problem and the surface path is.

Also adds the Unigram* -> Telegram* property rename to the cleanups.

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

UnigramDev/Unigram/develop • 1bc5aaf • 1 files, +6/-0
Log the exceptions the XAML handler swallows

OnUnhandledException marks almost everything handled and returns, so a handled
exception leaves no trace at all unless Diagnostics.ShowMemoryUsage happens to be
on, in which case it goes to a popup. That is how the calls window fails on .NET
10: something in AnimatedImage throws, the app carries on, and neither the log nor
ErrorReports has anything to say about it.

Logger.Error rather than TrackError: the app survived these, and a crash report
would claim otherwise. At the default packaged verbosity it reaches tdlib_log.txt,
which is readable after the fact.

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

UnigramDev/Unigram/develop • adcdff1 • 1 files, +19/-1
Register rendering on the presenter's own loader

AnimatedImageLoader.Current is [ThreadStatic], so RegisterRendering was resolving
whichever loader belonged to the calling thread, while every other call in the
presenter goes through its own _loader - Load, Remove, Activated, PopupActivated.
When the two differ, the presenter joins the wrong view's rendering list and its
WriteableBitmap is invalidated from that view's thread:

COMException 0x8001010E (RPC_E_WRONG_THREAD)
at WriteableBitmap.Invalidate()
at AnimatedImagePresenter.DrawFrame() AnimatedImage.cs:1499
at AnimatedImageLoader.OnRendering() AnimatedImage.cs:1827

which is what leaves the call window without video or lottie. The call was always
illegal; .NET Native called through the raw pointer and never checked, CsWinRT
does.

The off-thread path also logs, because it should not happen: something is calling
in from another thread, and the log will name the case rather than leaving it to
inference.

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

UnigramDev/Unigram/develop • 870308e • 1 files, +20/-0
The file checks moved, and the parse shows it

Same page, next startup: file handling 0.086s to 0.007s, 34% of the parse to
4%. The checks themselves cost what they always did - 1,080 of them, 0.094s,
87us each - they are just not on the TDLib thread any more. What is left is the
dictionary, the publish and the enqueue, 0.6us per update.

Also notes what the Reader/Pointer A/B will not show: both modes start timing
after the copy and the terminator scan, which the pointer path deleted, so it
compares parser against parser and understates the change to Receive.

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

#unigram