Skip to content

[BUG] mpvpaper picker blocks the shell for several seconds while loading full-resolution thumbnails #36

Description

@yuri368

Submission checklist

  • I have searched existing issues and confirmed this is not a duplicate.
  • I am using the latest available version of Noctalia.

Bug description

Opening the official noctalia/mpvpaper video wallpaper picker takes roughly 4–5 seconds before the panel becomes visible and usable. The request itself is accepted immediately, but Noctalia appears to stall while constructing or rendering the picker.

Mouse clicks and keyboard shortcuts issued during this delay are queued. When Noctalia becomes responsive again, multiple queued toggle requests may run in a burst and immediately open/close the panel several times. With an even number of clicks, the panel ends up closed, which initially makes the widget look unresponsive.

This occurs with 49 video files, many of them 1440p or 4K, in the configured video directory.

Steps to reproduce

  1. Install and enable the official noctalia/mpvpaper plugin.

  2. Set video_directory to a directory containing several dozen high-resolution videos (49 in my case, many at 2560x1440 or 3840x2160).

  3. Add the mpvpaper widget to the bar.

  4. Open the picker either by clicking the bar widget or by running:

    noctalia msg panel-toggle noctalia/mpvpaper:picker
  5. Observe that the IPC request is accepted immediately, but the picker does not become visible/usable for approximately 4–5 seconds.

  6. Click the widget several times during the delay. Once the shell responds, the queued toggles execute together and the panel may immediately open and close repeatedly.

Expected behavior

The video wallpaper picker should appear promptly and remain responsive while thumbnails are loaded asynchronously. Repeated input should not accumulate while thumbnail images are being decoded or uploaded.

Thumbnail files should be generated at a resolution appropriate for their displayed tile size instead of retaining the original video resolution.

Actual behavior

The panel manager accepts the open request immediately, but the visible picker is delayed by several seconds. During that period, Noctalia IPC and input handling can also become sluggish. Queued toggle actions are processed in a burst after the stall.

The generated thumbnail cache contains full-resolution frames. Examples from file:

JPEG image data, 2560x1440, components 3
JPEG image data, 3840x2160, components 3
JPEG image data, 4096x2160, components 3

There are currently 67 cached JPEG files using 35.9 MiB on disk. Although the compressed size is modest, decoding up to 24 full-resolution images for the first page can require hundreds of MiB of uncompressed texture data.

Logs / error output

The IPC command itself returns in about 30 ms and reports the panel as open:


$ time noctalia msg panel-toggle noctalia/mpvpaper:picker
ok

real    0m0.030s

$ noctalia msg status
{
  "barVisible": true,
  "panelOpen": true,
  "activePanelId": "noctalia/mpvpaper:picker",
  "locked": false
}


After several inputs were made during a stall, the debug log showed multiple queued toggles being handled in the same millisecond:


21:16:32.218 [DBG] [panel] panel manager: opened "noctalia/mpvpaper:picker"
21:16:35.358 [DBG] [panel] panel manager: closing "noctalia/mpvpaper:picker"
21:16:35.359 [DBG] [panel] panel manager: opened "noctalia/mpvpaper:picker"
21:16:35.359 [DBG] [panel] panel manager: closing "noctalia/mpvpaper:picker"
21:16:35.359 [DBG] [panel] panel manager: opened "noctalia/mpvpaper:picker"
21:16:35.359 [DBG] [panel] panel manager: closing "noctalia/mpvpaper:picker"

Noctalia version

text noctalia v5.0.0 (v5.0.0-beta.7-6-geaa207e7d62d) noctalia/mpvpaper plugin 1.0.7 (plugin API 9) mpvpaper 1.9

Compositor

Niri

Distribution

Arch-based

Environment information

Installation method: noctalia-git 5.0.0.r5004.geaa207e7d-2 (Arch Linux CN repository)
Kernel: 7.1.5-arch1-2
Compositor: niri 26.04
GPU: Intel Iris Xe Graphics (Alder Lake-P GT2), i915
Display: 2560x1600 at 1.5 scale
Video directory: local Btrfs filesystem (not NTFS or a removable drive)
Videos in configured directory: 49

Additional context

The current plugin implementation appears to extract thumbnails with mpv's image VO without applying a scale filter:

--frames=1 --start=10% --no-audio --vo=image --vo-image-format=jpg

PAGE_SIZE is 24, and thumbnail generation is queued for every video in the directory with four concurrent mpv processes. The cached JPEG frames retain the source video's resolution.

A possible fix would be to scale extracted frames to a reasonable maximum width (for example 480–512 px), generate/load thumbnails lazily for the visible page, and avoid synchronously decoding/uploading many full-resolution images while opening the panel.

Related but not identical reports:

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething isn't working

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions