Messages freeze applet

[uutzinger]

I encounter some stability issues when retrieving and attempting to send messages:

• Message retrieval can take a long time; I select a conversation and the previous messages do not display for quite some time.
• When conversation is loaded I can add to it but at some time, entering text is responding slowly to keystrokes. It can get to the point where the applet appears frozen and applet window no longer can be closed.

I pull repo from https://github.com/cosmic-utils/kdeconnect.git and then just build and just install. I make sure kdeconnect is not installed with dpkg -s kdeconnect.

[hepp3n]

Yeah I think this is the case, when we should build it with wgpu feature. It might be also optimization issues.

[hepp3n]

Hello again @uutzinger,

Could you please test this PR? #104 It's enables wgpu and removes optimizations.
Those are not needed. I understand reasoning behind that PR from some time ago which mentions to disable wgpu. If applet alone is not need wgpu that I think, SMS windows and settings require it for smooth working.

[uutzinger]

Did not fix the issue.
Initially messages load and conversation list populates. Then I can open a conversation and text line is responsive.
After a while response becomes sluggish and deleting text in the text entry window happens in chunks when delete key is kept pressing. Then text entry becomes unresponsive. Window responds to close button.

System is AMD Ryzen 7 48000H (16Gb RAM) with NVIDIA RTX 3060 Laptop GPU (6Gb VRAM) running on Pop!_OS 24.04 LTS with recent COSMIC dekstop updates.

AI summary of log files:

Summary

The applet has been crashing repeatedly — 22 exits with code 137 (SIGKILL) in the last 24 hours (PR104 installed 1 hr ago),

Errors and warnings

Time	Source	Message
Ongoing	winit_wayland	xdg_toplevel_icon_manager_v1 is not supported
Ongoing	sctk_adwaita	XDG Settings Portal did not return response in time
Aug 05 07:51	wgpu_hal::gles::egl	Re-initializing Gles context due to Wayland window
Aug 05 07:51	libEGL/Mesa	failed to get driver name for fd -1, failed to retrieve device information
Aug 05 07:51	wgpu_hal::vulkan	ERROR_SURFACE_LOST_KHR
Aug 05 07:29	kernel / NVRM	Out of memory [NV_ERR_NO_MEMORY]

Key observations

• Exit code 137 usually means the process was killed by the kernel or an external actor — often the OOM killer.
• The NVIDIA kernel driver logged an out-of-memory error at nearly the same time as the latest applet crash.
• The current system has a defunct/zombie kdeconnect-service process ([kdeconnect-serv] <defunct>, PID 46073).
• The kdeconnect-service itself (PID 3633) is still running.

Likely relation to PR #104

The original Cargo.toml explicitly avoided wgpu with this note:

"The wgpu/Vulkan stack costs ~100 MB of RSS per process and buys nothing for a 400px popup."

PR #104 enables wgpu, wayland, and winit features for libcosmic. The logs now show exactly the kind of GPU/Vulkan surface errors and memory pressure that the old comment warned about.

Verdict so far: the debug build and cargo test pass, but the runtime logs show the applet is unstable on this system with wgpu enabled — likely due to GPU memory exhaustion.

[hepp3n]

Sorry, I'm not understand this:

Verdict so far: the debug build and cargo test pass, but the runtime logs show the applet is unstable on this system with wgpu enabled — likely due to GPU memory exhaustion.

Does it means you run this in debug build? It will have lower performance. You should use release build instead.

To be honest I'm not sure yet what's the case. For me it works just fine. Maybe look into logs should be helpful.

You might also try to install from COSMIC Flatpak, the flatpak build. Maybe it will works better?

It looks like some memory leaks if it happens after a while.

[uutzinger]

I ran an AI code review.
First just for SMS messages, then for the whole app.
It identified the source of Message freezes.
I tested whether an AI agent could fix the SMS message issues. It successfully repaired them.
In separate message below I list the issues that I worked on.
I can post a full list of findings if you would like.
I can also create a pull request of the modifications my AI agent made but you might not be willing to let AI change your code.

[uutzinger]

Issues causing SMS freeze

✅ Unbounded message list re-rendered on every keystroke Because COSMIC/iced is immediate-mode, every keystroke in the input field triggers a full view() rebuild. With a long conversation (hundreds or thousands of messages), you are rebuilding hundreds of message bubbles, rich-text spans, and contact lookups per character typed. This is the main reason input becomes sluggish over time.

✅ Redundant conversation sort in the view: views.rs:185 re-sorts the conversation list on every render:
filtered.sort_by(|a, b| b.timestamp.cmp(&a.timestamp));
But app.conversations is already kept sorted in update() (app.rs:443, app.rs:698). This is wasted work every frame.

✅ O(n × m) contact lookups
get_contact_name() and get_contact_photo() (views.rs:720-735) do a linear scan of app.contacts for every conversation row and every received message bubble. If you have 500 contacts and 500 conversations, the conversation list alone does 250,000 string comparisons per render.

Expensive per-frame allocations:

• mixed_emoji_text() rebuilds rich-text spans for every visible message preview and body on every keystroke.
• view_contact_avatar() clones the entire avatar RGBA buffer; .
• view_conversations_list() rebuilds the contacts dropdown name list (contacts_by_name) from scratch every frame.
• conversation_matches_search() allocates query.to_lowercase() every render.

Message list never trimmed: Old messages are retained in self.messages while a thread is open; the rendered slice should be limited by messages_window_size, so the visible list is bounded.

✅ O(n²) message insertion on incoming cache: Initial SMS cache and full syncs are processed one MessageReceived event at a time(app.rs). For a long thread this becomes quadratic and duplicates work.

cosmic-ext-connect-applet Issues (unrelated to SMS freeze)

✅ Zombie kdeconnect-service process cosmic-ext-connect-applet/src/main.rs:577 spawns kdeconnect-service and drops the Child handle. If the child exits (because the real service is already running and the D-Bus name is taken) it is never reaped.

✅ Zombie settings process cosmic-ext-connect-applet/src/main.rs:378-380 spawns cosmic-ext-connect-settings and drops the Child handle, so it is never reaped.

✅ Zombie SMS window process cosmic-ext-connect-applet/src/main.rs:175 spawns cosmic-ext-connect-sms inside a thread but the original code dropped the Child handle without waiting, leaving a zombie on exit.

✅ Applet service watcher busy-loops cosmic-ext-connect-applet/src/backend.rs:528-541 retries fetch_devices() every 3 seconds for up to 90 seconds with no exponential back-off or cancellation, keeping the applet awake after the bus disappears.