Skip to content

Windows: the panel and the clipboard history stop freezing - #10

Merged
adrbn merged 4 commits into
mainfrom
fix/windows-panel-and-history-lag
Oct 26, 2026
Merged

adrbn merged 4 commits into
mainfrom
fix/windows-panel-and-history-lag

Conversation

@adrbn

@adrbn adrbn commented Oct 26, 2026

Copy link
Copy Markdown
Owner

Reported from a work PC on 2.0.3: the app rames, the clipboard history takes
forever to open and then freezes and refuses to scroll, and the menu at the
bottom of the panel refuses to close.

Four causes, all of them read out of the code:

  • Every thumbnail was decoded on the interface's thread before the list
    drew a single row (ClipboardController.Thumbnail). Two hundred screenshots
    is two hundred disk reads and decompressions before anything appears.
  • Every piece that arrived rebuilt every row. A picture decoded, the words
    read in another, a page's title, a file's icon — each raised Changed, and
    each rebuilt the whole list. The rows go out from under the pointer and the
    scroller goes back to the top, which is what "refuses to scroll" was.
  • The working set was emptied once things went quiet (Memory), so the
    next panel or list read itself back from disk — with an antivirus in between,
    seconds of nothing.
  • The ··· menu is a window of its own, so choosing something in it is a
    click outside the panel: the global click watcher closed the panel from under
    the menu, and the menu was left on screen with nothing to dismiss it.

Test plan

  • CI: build and tests on windows-latest, update-button and shortcut jobs green
  • On a real PC with a few hundred items in the history: Win+Shift+8 appears
    at once, pictures fill in as they come, scrolling works while they do
  • The ··· menu opens, "Open at Login" toggles with the panel still up, and
    the menu closes on the next click outside

adrbn added 4 commits October 26, 2026 12:21
A thumbnail is a read from disk and a decompression, and the list did every
one of them on the interface's thread before it drew a single row: a history
full of screenshots took seconds to appear, and answered nothing while it did.
Decoded off that thread, and drawn as each one arrives.
What the list waits for arrives one piece at a time — a picture decoded, the
words read in another, a page's title, a file's icon — and each piece rebuilt
every row. A list rebuilt a hundred times over cannot be scrolled: the rows go
out from under the pointer, and the scroller goes back to the top each time.
Rebuilt once they have settled, and put back where the user was reading.
…m in again

Handing every page back to Windows once things went quiet read well in Task
Manager, but the next panel or list then read itself back from disk — with an
antivirus between the two, that is seconds of nothing before anything appears.
The collection stays; the trimming goes.
The menu is a window of its own, so choosing something in it is a click
outside the panel — which closed the panel from under it, leaving the menu on
screen with nothing above it to dismiss it. While it is up, the panel stays;
when the panel goes, the menu goes with it.
@adrbn
adrbn merged commit 3bc4565 into main Oct 26, 2026
5 checks passed
@adrbn
adrbn deleted the fix/windows-panel-and-history-lag branch October 26, 2026 11:39
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant