This code already isn't used (or even bundled) in the Firefox PDF Viewer, and it also slightly reduces the number of import maps that need to be maintained.
Currently we have no less than three different, but very similar, factories for reading built-in CMap files, standard font files, and wasm files on the main-thread.[1]
These factories were added at different points in time, since I cannot imagine that we'd add essentially three copies of the same code otherwise.
Nowadays these factories are often not even used[2], since worker-thread fetching is used whenever possible to improve performance. In particular, they will *only* be used when either:
- The PDF.js library runs in Node.js environments.
- The user manually sets `useWorkerFetch = false` when calling `getDocument`.
- The user provides custom `CMapReaderFactory`, `StandardFontDataFactory`, and/or `WasmFactory` instances when calling `getDocument`.
By replacing these factories with *a single* new `BinaryDataFactory` factory/option the number of `getDocument` options are thus reduced, which cannot hurt.
This also reduces the total bundle-size of the Firefox PDF Viewer a little bit, and it slightly reduces the number of import maps that need to be maintained.
*Please note:* For users that provide custom `CMapReaderFactory`, `StandardFontDataFactory`, and `WasmFactory` instances when calling `getDocument` this will be a breaking change, however it's unlikely that (many) such users exist.
(The *internal* format data-format of `CMapReaderFactory` was changed in PR 18951, and there hasn't been a single question/complaint about it in well over a year.)
---
[1] Any new functionality could easily lead to more such factories being added in the future, which wouldn't be great.
[2] Note that the Firefox PDF Viewer no longer use these factories, since it "forcibly" sets `useWorkerFetch = true` during building.
The WebGPU feature hasn't been released yet but it's interesting to see how
we can use it in order to speed up the rendering of some objects.
This patch allows to render mesh patterns using WebGPU.
I didn't see any significant performance improvement on my machine (mac M2)
but it may be different on other platforms.
Currently it's only possible to trigger page-render debugging through the page number, but when looking at the /Pages tree it's often not immediately obvious what the page number actually is.
However, the /Ref of the page is directly available and it's thus handy to be able to use that one instead to enable page-render debugging.
The goal of this patch is to remove the noice we've in the logs:
```
0:09.36 INFO Console message: [JavaScript Warning: "Script terminated by timeout at:
reset@resource://pdf.js/web/viewer.mjs:11773:7
EventListener.handleEvent*#enableGlobalSelectionListener@resource://pdf.js/web/viewer.mjs:11787:12
render@resource://pdf.js/web/viewer.mjs:11716:20
async*#renderTextLayer@resource://pdf.js/web/viewer.mjs:12108:28
draw/resultPromise<@resource://pdf.js/web/viewer.mjs:12575:53
promise callback*draw@resource://pdf.js/web/viewer.mjs:12570:8
renderView@resource://pdf.js/web/viewer.mjs:7872:14
forceRendering/<@resource://pdf.js/web/viewer.mjs:13963:29
" {file: "resource://pdf.js/web/viewer.mjs" line: 11773}]
```
Unfortunately, eslint-plugin-import depends on eslint 9. This plugin doesn't seem to be
actively maintained (lot of open issues and PRs).
Fortunately there's a fork of the plugin that doesn't support eslint 10 yet but is actively maintained.
So this PR changes the eslint version to 10 and replaces eslint-plugin-import with eslint-plugin-import-x.
Instead of having all the code for the new debugger in a single file,
split it into multiple files.
This makes it easier to navigate and maintain the codebase.
It'll be make hacking and fixing bugs in the debugger easier.
