Remove thumbnail sidebar's rootMargin prefetch — still crashed opening it - #156
Merged
Conversation
Confirmed by testing: main-view scrolling no longer crashes (#155), but opening the thumbnail sidebar at all still did, even with the lazy-load/evict cycle #155 added for it. Root cause: rootMargin percentages are relative to the *root's own* size, not the viewport - thumbObserver's root is the sidebar, sized around each ~150-250px thumbnail item (image + label), while pageObserver's root (contentEl) is sized around each often-near- full-viewport main-view page. The same '100% 0px' margin that only ever brings 1-2 main-view pages into range at once fits several times that many thumbnails into an equivalent pixel margin - each still triggering a full, real-page-resolution rasterization (ensurePageImage() has no separate cheap/low-res path for thumbnail- only use), just to fill in a 140px-wide image. Opening the sidebar on a long document meant a burst of many simultaneous full rasterizations at once, not the 1-2 at a time the main view actually needed. Removed rootMargin entirely for thumbObserver (defaults to 0px) - a thumbnail popping in slightly after it's actually scrolled to is an acceptable trade-off for a navigation aid, unlike the main reading view, which keeps its own prefetch margin.
This was referenced Jul 31, 2026
Closed
pull Bot
pushed a commit
to ben-vargas/supernote-obsidian-plugin
that referenced
this pull request
Jul 31, 2026
Two issues reported after philips#156 (thumbnail rootMargin fix): thumbnails "pop" once their image loads (nothing reserved the box's size before that), and scrolling the thumbnail sidebar for a while (~50 pages) still crashed. These are likely the same bug. An <img> with no src/dimensions collapses to ~0 height, so it visibly pops to full size once ensurePageImage() sets `src` - but that's not just cosmetic: every pop shifts every later thumbnail's position, reflowing the whole sidebar. A reflow that moves many items can re-trigger thumbObserver for all of them at once, even though nothing was actually scrolled - turning a smooth scroll through a long sidebar into a cascade of extra load/evict churn well beyond whatever's actually visible at any given moment, which philips#156's zero-rootMargin fix alone doesn't bound. Sets each thumbnail <img>'s aspect-ratio from the note's own pageWidth/pageHeight (uniform across all pages, already used for nativeWidth/nativeHeight) before any image data exists - width is already fixed at 100% of the item via CSS, so aspect-ratio derives the correct height immediately. A stable layout from the start means an item's intersection state can only change because of an actual scroll, not a sibling loading in and shifting everything below it.
pull Bot
pushed a commit
to ben-vargas/supernote-obsidian-plugin
that referenced
this pull request
Jul 31, 2026
Reported after testing 3.0.2-beta.17 (issue philips#154): scrolling the thumbnail sidebar slowly is fine, but scrolling quickly through it still crashes - even bounded to "only what's currently visible" (philips#156) and with the pop/reflow cascade fixed (philips#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.
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
Follow-up to #155 (merged). The reporter confirmed main-view scrolling on the 100-page note no longer crashes, but opening the thumbnail sidebar at all still did, even with #155's lazy-load/evict cycle for thumbnails.
Root cause:
rootMarginpercentages are relative to the root element's own size, not the viewport.thumbObserver's root is the sidebar, sized around each ~150-250px thumbnail item (image + label).pageObserver's root (the main content area) is sized around each often-near-full-viewport page. The same'100% 0px'margin that only ever brings 1-2 main-view pages into range at once fits several times that many thumbnails into an equivalent pixel margin - each still triggering a full, real-page-resolution rasterization (ensurePageImage()has no separate cheap/low-res path for thumbnail-only loads, just to fill in a 140px-wide image). Opening the sidebar on a long document meant a burst of many simultaneous full rasterizations, not the 1-2 at a time the main view actually needed.Change
Removed
rootMarginentirely forthumbObserver(defaults to0px) - a thumbnail popping in slightly after it's actually scrolled to is an acceptable trade-off for a navigation aid, unlike the main reading view, which keeps its own prefetch margin unchanged.What I could not verify
Same caveat as #151/#155: no Obsidian/Electron/X server available in my environment. Verified via
tsc/eslint/the test suite and reasoning aboutIntersectionObserver'srootMarginpercentage semantics, not by actually opening the thumbnail sidebar on the reported 100-page note. Please verify on that document before considering #154 closed.Test plan
npx tsc --noEmit- cleannpx eslint src/main.ts- 0 errorsnpx vitest run- 95 passednpm run build- clean