PDF text selection extremely laggy when zoomed in on high-DPI display (Windows scaling 200%)

Selecting text in the built-in PDF reader becomes extremely laggy after navigating through multiple pages when the PDF is zoomed in. The cursor stutters severely and there is a significant delay between mouse movement and text selection.

How it triggers (important):

Open a PDF and zoom in (e.g., 250%+ in the PDF reader's zoom control) — text selection is smooth at first
Navigate forward/backward through several pages
After flipping through a few pages, text selection starts to lag and gets progressively worse
The more pages you navigate, the worse the lag becomes
This suggests that text layer DOM from previously viewed pages may not be properly cleaned up, causing hit-testing to traverse an ever-growing number of elements.

Key observation: This only happens when both conditions are met:

Windows display scaling (Settings → System → Display → Scale) is set to 200% — this is the OS-level DPI scaling, not the PDF reader's zoom
The PDF is zoomed in beyond its default size within Zotero's PDF reader
At 200% Windows display scaling with the PDF at default zoom (fit page), text selection remains smooth. At 100% Windows display scaling, text selection is smooth at any PDF zoom level, even after navigating many pages. The problem only appears when high Windows DPI scaling and PDF zoom-in are combined.

System info

OS: Windows 11
Zotero version: 9.0.6 (pdf.js 5.4.0)
Display: 16" 3200×2000, Windows display scaling 200%
CPU: Intel Core Ultra 9 185H
GPU: Intel Arc Graphics (integrated) + NVIDIA RTX 4060 Laptop GPU
What I've already tried

Troubleshooting Mode (Safe Mode) — disabled all plugins, problem persists. Not a plugin issue.
about:config tweaks — all ineffective:
layers.acceleration.disabled = false (default)
gfx.webrender.all = true
layout.css.devPixelsPerPx = 1.0 and 2.0 (no improvement)
general.smoothScroll = false
Dedicated GPU — forced Zotero to use the NVIDIA RTX 4060 via Windows Graphics Settings. No improvement.
CSS injection — injected content-visibility: auto and contain: layout style paint into text layer spans via userContent.css. No improvement.
CPU priority / affinity — no meaningful improvement.
The only workaround (with a major downside)

Setting "Override high DPI scaling behavior → System" in zotero.exe Properties → Compatibility makes text selection smooth at any PDF zoom level, even after navigating many pages. However, this causes the entire Zotero UI to become noticeably blurry because Windows stretches the application bitmap.

This confirms the root cause is related to how Zotero/pdf.js handles text layer DOM under high DPI scaling — the DOM accumulates text layer spans from viewed pages, and under 200% Windows display scaling each span is more expensive for CPU-side hit-testing.

Related upstream issue

mozilla/pdf.js#15131 — "Don't recompute the text layer when zooming"
zotero/zotero#4809 — open issue about slow PDF rendering
My understanding of the root cause

DOM hit-testing in browsers is a CPU-only, single-threaded operation. Under 200% Windows display scaling, the pdf.js text layer generates significantly more elements per page. As the user navigates through pages, text layer DOM from previously viewed pages appears to accumulate without proper cleanup, and every mouse movement triggers a traversal of all these elements for coordinate intersection. The combination of high DPI (more spans per page) + PDF zoom-in + DOM accumulation from page navigation creates a compounding effect that overwhelms the CPU.

Request

High-DPI displays with 200%+ Windows display scaling are increasingly common on modern laptops (3K/4K screens). Could the team consider:

Investigating whether text layer DOM from previously viewed pages is properly cleaned up
Optimizing the text layer DOM structure for high-DPI + zoom scenarios (e.g., virtualizing off-screen spans, reducing span count)
Applying pointer-events: none to off-screen or previously-viewed text layer spans to reduce hit-testing scope
Any other architectural improvements to reduce hit-testing overhead under high Windows display scaling
Happy to provide any additional diagnostics if needed.
Sign In or Register to comment.