The cache has been added in #3312 in 2013 and a lot of things changed since.
Having too many cached accelerated canvases can lead to have to move their data from the GPU to the RAM
which is costly.
So this patch:
- removes all the cached canvases;
- destroys the useless canvases in order to free their associated memory asap;
- slightly rewrite canvas.js::_scaleImage to avoid too much canvas creation.
Using the Fetch API simplifies and shortens the `downloadFile` function considerably, since among other things it handles redirects[1] by default.
Also, the regular expression in `downloadManifestFiles` can be replaced with a simple string function now.
---
[1] Implementations of the Fetch API should already prevent e.g. redirect loops and limit the total number of redirects allowed.
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.
For the Python-based workflows we were already using `pip` caching [1],
but sadly this isn't fully functional at the moment because the caching
functionality uses `requirements.txt` to determine when to create or
invalidate the cache. However, we have two different `pip` install
commands but only a `requirements.txt` for one of them (the Fluent
linter), which means that the other job (the font tests) will not
populate the cache with its dependencies.
This can be seen by opening any font tests or Fluent linting build and
noticing that they report the exact same cache key even though their
dependencies are different. In the installation step the dependencies
are reported as "Downloading [package].whl" instead of the expected
"Using cached [package].whl".
This commit fixes the issue by explicitly defining a `requirements.txt`
file for both jobs and pointing the caching functionality to the
specific file paths to make sure that unique caches with the correct
package data are used. While we're here we also align the syntax and
step titles in the files for consistency.
[1] https://github.com/actions/setup-python?tab=readme-ov-file#caching-packages-dependencies
The `setup-node` action contains built-in support for caching [1], so
this commit makes sure we use it for all Node.js-based workflows to
reduce workflow execution time.
Note that, contrary what one might expect [2], the `node_modules`
directory is deliberately not cached because it can conflict with
differing Node.js versions and because it's not useful in combination
with `npm ci` usage which wipes the `node_modules` folder
unconditionally. Therefore, the action instead caches the global `npm`
cache directory instead which does not suffer from these problems and
still provides a speed-up at installation time.
[1] https://github.com/actions/setup-node?tab=readme-ov-file#caching-global-packages-data
[2] https://github.com/actions/setup-node/issues/416
[3] https://github.com/actions/cache/issues/67
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.
This reverts commit d618a2bc7ebe550cfcef31df8ddd0c8a12cf6bf1.
Unfortunately it did not fix the hanging actions for the locale update
job; fixing the issue is tracked in #20813.
Trying to resolve the same `objId` more than once would be a bug elsewhere in the code-base, since that should never happen, hence update the `resolve` method to prevent that.
The `BaseCMapReaderFactory`, `BaseStandardFontDataFactory`, and `BaseWasmFactory` classes are all very similar, and the only difference is really in their respective `fetch` methods.
By have the worker-thread "compute" the complete `filename` it's possible to simplify the `BaseCMapReaderFactory.prototype.fetch` method, which will allow future improvements to all of these classes.
A couple of things to note:
- This code is unused, and it's not even bundled, in the Firefox PDF Viewer.
- In browsers it's unused by default, and worker-thread fetching will always be used when possible since that's more efficient.
*Please note:* For users that provide a custom `CMapReaderFactory` instance when calling `getDocument` this could be a breaking change, however it's unlikely that any such users exist.
(The *internal* format of this data was changed previously in PR 18951, and there hasn't been a single question/complaint about it in well over a year.)
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.
