There's no point in first checking if a value exists in a Set before deleting it, and this is just a left-over from before the code used Maps and Sets.
Also, remove a couple of unnecessary comments describing how `Set.prototype.add` works (when those where added there wasn't much Set usage in the code-base).
In cases where all the requested chunks are already available, and dispatching a range-request thus isn't necessary, there's no point in creating an unused `requestId` nor keeping track of it since it'll never be accessed given the early return.
- `convertRGBToRGBA` ignored the `byteOffset` of the source, which isn't zero
when e.g. the data of an uncompressed image is read directly from the file,
and it threw when the source wasn't 4-byte aligned. In that case all the
pixels are now converted one by one.
It also used `len >> 2`, which overflows for sources larger than 2 GiB.
- In `ImageResizer.#rescaleImageData`, when the image had to be converted in
several chunks:
- if the chunk height divided the image height, the last chunk was converted
with the full image height;
- the rows were sampled relatively to each chunk, hence a chunk height which
isn't a multiple of `2 ** K` shifted the sub-sampling grid and left the
last rows of the result empty. They're now sampled on the image grid;
- the chunk height is rounded to a multiple of 4 when possible, in order to
keep the RGB data aligned;
- if not even a single row fitted in the buffer, the loop never ended.
Expose function input/output counts and reject incompatible shading and
stitching functions.
Reuse interpolation buffers instead of allocating cube vertices per call.
Skip axes at integer sample coordinates, fixing invalid sample accesses
for Size=1 axes.
For functions with more than eight inputs, use simplex interpolation.
It reads at most m + 1 sample-table entries per output for m inputs,
instead of up to 2^m. It can produce different values from multilinear
interpolation.
Resizing the canvas in #getAscent reset ctx.font to 10px sans-serif
without updating #canvasCtxFonts. A subsequent 30px run using the
same family could skip setting the font and get an incorrect width.
Remove the resizing left over from the pixel-based fallback removed
in PR #19399. Add a regression test comparing 30px and 33px runs.
The `FontInfo` class doesn't use the `extra` properties for anything, and they are already exposed via the `FontFaceObject` instance which is how the debuggers access those properties.
Prior to PR 20197 each font-instance had just a single copy of all its relevant font-properties on the main-thread, however that's unfortunately no longer the case.
Given how the compilation was implemented, every single time that a font-property is accessed on the main-thread it'll now be re-parsed. Not only does this seem inefficient, especially for properties needed e.g. during text-rendering, but it'll lead to (potentially) a lot of duplicated object creation.
Consider what currently happens when rendering all pages of the following PDFs:
- `tracemonkey.pdf` contains `24` separate fonts, but the `fontMatrix`-property is re-parsed a whopping `1009` times (once per `showText` operator).
- `standard_fonts.pdf` contains `14` separate fonts, however we create no less than `186` separate `StandardFontInfo` instances.
- `xfa_bug1716816.pdf` contains `4` separate fonts, however we create no less than `45` separate `CssFontInfo` instances.
This is obviously not limited to just the font-properties listed above, but those are mere examples to illustrate the problem.
By shadowing the font-property getters on the main-thread, obviously with the exception of `FontInfo.prototype.data`, we only need to parse each font-property *once* per font-instance.
*Note:* Unfortunately this *increases* the size of the `gulp mozcentral` bundle by `792` bytes, but that cannot really be helped since this seems like the correct thing to do regardless.
Currently the `FontInfo.prototype.{data, cssFontInfo, systemFontInfo}` getters duplicate virtually the same code when reading buffer-data, which seems completely unnecessary.
*Note:* This reduces the size of the `gulp mozcentral` bundle by `738` bytes, and with the upcoming worker-rendering this saving will be doubled.
- All embedded font data, regardless of how it's specified in the PDF, is always converted into OpenType in the worker-thread. This has been the case since "forever" in the PDF.js project, hence the value of `Font.prototype.mimetype` never varies (when actually set).
- With the introduction of the CSS Font Loading API, in the font-loading code, the `mimetype` property is no longer used *by default* in the main-thread.
- Given that `Font.prototype.mimetype` is either a string or `null`, the way that PR 20197 implemented the serialization/deserialization isn't actually correct since an explicit `null` value is being converted into a `"null"` string.
Tim van der Meij