Painting is significantly slower (UI freezes) in Chrome/Chromium when viewing issue20722.pdf #21946

This file is the dark version from #20722, made with Ghostscript's setcolortransfer, so its graphics states carry a transfer function (/TR). pdf.js draws /TR by setting the canvas filter to an SVG feComponentTransfer filter (the "TR" case in src/display/canvas.js), and that filter then runs on every fill and stroke. Chromium is really slow at that. A quick test page with 500 small filled rects, rendered with pdfjs-dist 6.3.289 in headless Chromium 141, took about 15 ms without /TR and 3 to 13 seconds with it.

On viewer.html: the setting that matters here is enableHWA. The viewer turns it on (web/app_options.js), but getDocument() defaults to false, and then the page canvas is created with willReadFrequently: true (src/display/canvas_factory.js), which keeps it on the CPU in Chrome. Worth trying in your app:

pdfjsLib.getDocument({ url, enableHWA: true })

The headless run had no GPU, so how much that helps with this file couldn't be measured here.