Avatars: full-size photos for 32 px, fetched as full views, all redrawn per arrival #239

New issue

Closed

opened 2026-10-21 19:22:20 +00:00 by littlefox · 1 comment

littlefox commented

2026-10-21 19:22:20 +00:00

Owner

Found in the performance review (#230, D-058).

app/src/avatar.rs and Kom::avatar (crates/kom-client/src/profile.rs):

Full-size pictures for 32 px avatars. The avatar is the first picture in the person's presentation. People paste photos of several MB there. It is kept as a full-size base64 data: URL in CACHE for the session, and every img on screen decodes the full picture to draw it at 32 px.
- Scale it down once (to ~96 px, for 3× screens) and keep only that: on a canvas on the web, with image on desktop.
- Or store it as a small blob: URL.
Fetching it builds a full view. Kom::avatar calls self.view(presentation). That builds a whole TextView, including a get-text-stat for every comment to the presentation. Old presentations can have many comments. It only needs the body. view also counts the presentation as a seen FAQ; preview or a body-only path would do.
One arriving avatar redraws them all. Every Avatar reads the whole CACHE map, so each picture that arrives redraws every avatar on screen. In a long thread that is N pictures × N avatars. Give each person their own signal (or a memo per person).
Pictures are also kept as raw bytes in kom-client's bodies cache (the presentation text) for the whole session (#236).

Found in the performance review (#230, D-058). `app/src/avatar.rs` and `Kom::avatar` (`crates/kom-client/src/profile.rs`): - **Full-size pictures for 32 px avatars.** The avatar is the first picture in the person's presentation. People paste photos of several MB there. It is kept as a full-size base64 `data:` URL in `CACHE` for the session, and every `img` on screen decodes the full picture to draw it at 32 px. - Scale it down once (to ~96 px, for 3× screens) and keep only that: on a canvas on the web, with `image` on desktop. - Or store it as a small `blob:` URL. - **Fetching it builds a full view.** `Kom::avatar` calls `self.view(presentation)`. That builds a whole `TextView`, including a `get-text-stat` for every comment to the presentation. Old presentations can have many comments. It only needs the body. `view` also counts the presentation as a seen FAQ; `preview` or a body-only path would do. - **One arriving avatar redraws them all.** Every `Avatar` reads the whole `CACHE` map, so each picture that arrives redraws every avatar on screen. In a long thread that is N pictures × N avatars. Give each person their own signal (or a memo per person). - Pictures are also kept as raw bytes in `kom-client`'s `bodies` cache (the presentation text) for the whole session (#236).

littlefox added this to the 0.6: Performance milestone

2026-10-21 19:22:20 +00:00

littlefox added the

area/ui

kind/bug

labels

2026-10-21 19:22:20 +00:00

littlefox referenced this issue from a pull request that will close it,

2026-10-22 04:39:08 +00:00

Avatars: scaled down once, fetched light, redrawn one at a time #266

littlefox closed this issue

2026-10-22 05:10:00 +00:00

littlefox referenced this issue from a commit

2026-10-22 05:10:01 +00:00

Avatars: scaled down once, fetched light, redrawn one at a time

littlefox commented

2026-10-22 06:16:01 +00:00

Author

Owner

Merged in #266; main run #441 green. Verified: profile spec on three profiles (a 600 px picture is kept as ≤192 px), side-column, presence, thread and channel-posts specs; tools/perf.sh: after 25 pages of a channel's posts the app's memory is 33 MB, down from 89 MB.

Merged in #266; main run #441 green. Verified: profile spec on three profiles (a 600 px picture is kept as ≤192 px), side-column, presence, thread and channel-posts specs; `tools/perf.sh`: after 25 pages of a channel's posts the app's memory is 33 MB, down from 89 MB.

littlefox referenced this issue

2026-10-22 10:41:54 +00:00

Memory grows without bound in big meetings (close to 1 GiB) #227