1
0
Fork 0
mirror of https://github.com/mozilla/pdf.js.git synced 2025-04-24 09:08:07 +02:00

[api-minor] Remove the forceClamped-functionality in the Streams (issue 14849)

As it turns out, most of the code-paths in the `PDFImage`-class won't actually pass the TypedArray (containing the image-data) to the `ColorSpace`-code. Hence we *generally* don't need to force the image-data to be a `Uint8ClampedArray`, and can just as well directly use a `Uint8Array` instead.

In the following cases we're returning the data without any `ColorSpace`-parsing, and the exact TypedArray used shouldn't matter:
 - b72a448327/src/core/image.js (L714)
 - b72a448327/src/core/image.js (L751)

In the following cases the image-data is only used *internally*, and again the exact TypedArray used shouldn't matter:
 - b72a448327/src/core/image.js (L762) with the actual image-data being defined (as `Uint8ClampedArray`) further below
 - b72a448327/src/core/image.js (L837)

*Please note:* This is tagged `api-minor` because it's API-observable, given that *some* image/mask-data will now be returned as `Uint8Array` rather than using `Uint8ClampedArray` unconditionally. However, that seems like a small price to pay to (slightly) reduce memory usage during image-conversion.
This commit is contained in:
Jonas Jenwald 2022-04-28 14:04:20 +02:00
parent b72a448327
commit fbf6dee8ee
8 changed files with 44 additions and 94 deletions

View file

@ -36,12 +36,6 @@ describe("stream", function () {
const result = predictor.getBytes(6);
expect(result).toEqual(new Uint8Array([100, 3, 101, 2, 102, 1]));
predictor.reset();
const clampedResult = predictor.getBytes(6, /* forceClamped = */ true);
expect(clampedResult).toEqual(
new Uint8ClampedArray([100, 3, 101, 2, 102, 1])
);
});
});
});