Debounce thumbnail loading so a fast scroll skips transient flybys - #159
Merged
Conversation
Reported after testing 3.0.2-beta.17 (issue #154): scrolling the thumbnail sidebar slowly is fine, but scrolling quickly through it still crashes - even bounded to "only what's currently visible" (#156) and with the pop/reflow cascade fixed (#158). A fast scroll flings most thumbnails past the viewport within a couple hundred milliseconds. Every one of those still triggered a full, real-page-resolution rasterization (ensurePageImage() has no separate cheap/low-res path for thumbnails) immediately on becoming intersecting, then got evicted again almost as fast once it left - dozens of full rasterizations back-to-back in quick succession during one fast flick through a long sidebar. Debounces the *load* trigger ~200ms per thumbnail (not eviction - freeing memory promptly on scroll-away has no downside either way): a thumbnail only actually loads if it's still intersecting once its timer fires, so one that was only ever transiently in view during a fast scroll never triggers a rasterization at all. Only pages the user actually lingers near for a moment do. Also clears any pending per-page debounce timers in onLoadFile()'s reset and onClose() - disconnecting the observer stops new callbacks, but doesn't cancel timers an earlier one already scheduled, which could otherwise fire after a file switch and redundantly load a page from a note the user's already navigated away from.
This was referenced Jul 31, 2026
This was referenced Jul 31, 2026
pull Bot
pushed a commit
to ben-vargas/supernote-obsidian-plugin
that referenced
this pull request
Jul 31, 2026
Integrates supernote-typescript#41 (merged to that repo's main), closing supernote-typescript#40: toImage() now accepts a `scale` downsample factor and decodes directly at the reduced resolution (RattaRLEDecoder.decodeAtScale) rather than decoding at full resolution and shrinking afterward - a full pageWidth x pageHeight buffer is never allocated. On a real 1404x1872 page that's a ~10MB decode (full res) vs. ~100KB (scale 10) - confirmed in that PR. Threads an optional `scale` parameter through the whole rasterization path: ImageConverter.convertToImages -> WorkerPool.processPages/ processChunk -> the SupernoteWorkerMessage sent to the Worker -> supernote-typescript's toImage() itself. Previously, SupernoteView's thumbnail sidebar reused ensurePageImage() - the exact same full-page-resolution path the main view uses - just to fill in a ~140px preview, paying the same decode/memory cost as actually viewing the page (the root inefficiency behind issue philips#154's crash trail: philips#156's rootMargin fix and philips#159's debounce both worked around *how often* this fired, not *how expensive* each individual thumbnail load was). Gives thumbnails their own entirely separate state (thumbnailDataUrl/thumbnailLoadPromise) and load/evict cycle (ensureThumbnail()/evictThumbnail()) at THUMBNAIL_SCALE (4, chosen so a typical ~1400px-wide page decodes to ~350px - comfortably above the sidebar's own width with headroom for higher-DPI displays), fully decoupled from ensurePageImage()/evictPageImage()'s full-resolution main-view state - a thumbnail being visible no longer implies (or requires) the main view's own image to load, and vice versa, since neither shares a resolution or cost with the other anymore.
philips-clanker
added a commit
that referenced
this pull request
Aug 1, 2026
Requested for testing on desktop, where DevTools' Memory tab is available to cross-check against: "scrolling all 100 pages still causes a crash" even after #155/#156/#158/#159's fixes, and it isn't obvious from the outside whether eviction is actually keeping up or something's still accumulating. Logs every page load/evict (main view and thumbnails alike, since both go through the same ensurePageImage()/evictPageImage()) with a rough memory estimate for that page (decoded ImageBitmap + canvas backing store - the latter often the larger of the two, up to 9x the bitmap's pixel count at capped 3x devicePixelRatio) and a running total across every currently-loaded page. Watching whether "currently loaded" keeps climbing over a long scroll (something isn't actually being freed) or stays roughly bounded (eviction is working, and the cause is something else - e.g. pure CPU/GC pressure from rasterization itself, see supernote-typescript#40's thumbnail-resolution angle on that) should narrow down what's actually still going wrong.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Addresses the "scrolling quickly still crashes" half of the 3.0.2-beta.17 test report on #154 (scrolling slowly was already fine after #158's pop/reflow fix).
A fast scroll through the thumbnail sidebar flings most thumbnails past the viewport within a couple hundred milliseconds. Every one of those still triggered a full, real-page-resolution rasterization (there's no separate cheap/low-res path for thumbnails) the instant it became intersecting, then got evicted again almost as fast once it left - meaning a quick flick through a long sidebar fired off dozens of full rasterizations back-to-back in rapid succession, which #156's "only load what's visible" fix didn't prevent (each one genuinely was visible, if only for a moment).
Change
Debounces the load trigger ~200ms per thumbnail: it only actually rasterizes if it's still intersecting once its timer fires, so a thumbnail that was only ever transiently in view during a fast scroll never triggers a load at all - only ones the user actually lingers near for a moment do. Eviction is deliberately not debounced - freeing memory promptly on scroll-away has no downside.
Also clears any pending per-page timers in
onLoadFile()'s reset andonClose()- disconnecting the observer stops new callbacks but not timers an earlier one already scheduled, which could otherwise fire after a file switch and redundantly load a page from a note the user's already navigated away from.Downscaling thumbnails (raised in the issue, not done here)
The reporter also asked about actually downscaling thumbnail resolution instead of/alongside debouncing. That would be the more complete fix - thumbnails don't need full page resolution at all - but the rasterization pipeline (
toImage/extractPageRenderDatain thesupernote-typescriptsubmodule) has no scale/resolution parameter today; adding one is a bigger change than this PR, touching a different repo. Debouncing was the faster, lower-risk fix to try first for the specific "fast scroll" symptom - happy to look into downscaling separately if this isn't enough on its own.What I could not verify
Same caveat as the last several PRs here: no Obsidian/Electron/X server in my environment. Verified via
tsc/eslint/tests and reasoning about the debounce's effect on IntersectionObserver's fast-scroll callback pattern, not by actually fast-scrolling the reported sidebar on a real device.Test plan
npx tsc --noEmit- cleannpx eslint src/main.ts- 0 errorsnpx vitest run- 95 passednpm run build- clean