After adding support for XObject Form rendering, the next was to display
XObject images. This commit adds this initial support,
Images come in many shapes and forms: encodings: color spaces, bits per
component, width, height, etc. This initial support is constrained to
the color spaces we currently support, to images that use 8 bits per
component, to images that do *not* use the JPXDecode filter, and that
are not Masks. There are surely other constraints that aren't considered
in this initial support, so expect breakage here and there.
In addition to supporting images, we also support applying an alpha mask
(SMask) on them. Additionally, a new rendering preference allows to skip
image loading and rendering altogether, instead showing an empty
rectangle as a placeholder (useful for when actual images are not
supported). Since RenderingPreferences is becoming a bit more complex,
we add a hash option that will allow us to keep track of different
preferences (e.g., in a HashMap).
Interpolation is needed in more than one place, and I couldn't find a
central place where I could borrow a readily available interpolation
routine, so I've implemented the first simple interpolation object. More
will follow for more complex scenarios.
The existing try_create_from_serialized_byte_buffer function accepts a
ByteBuffer, but in reality it requires only a ReadonlyBytes, since
internally the only thing it does is calling buffer.bytes(). There is
thus no reason to have a function that simply accepts ReadonlyBytes, and
implement the former in terms of the newer.
Arrays of float numbers are common in many PDF objects, and thus to
avoid code repetition I'm introducing a new method to ArrayObject that
will return exactly that.
ColorSpaces now can tell users how many components they expect, and the
default decode array that should be used when converting unit bit
sequences into color space component input values during image
rendering.
ColorSpaces can be specified in two ways: with a stream as operands of
the color space operations (CS/cs), or as a separate PDF object, which
is then referred to by other means (e.g., from Image XObjects and other
entities). These two modes of addressing a ColorSpace are slightly
different and need to be addressed separately. However, the current
implementation embedded the full logic of the first case in the routine
that created ColorSpace objects.
This commit refactors the creation of ColorSpace to support both cases.
First, a new ColorSpaceFamily class encapsulates the static aspects of a
family, like its name or whether color space construction never requires
parameters. Then we define the supported ColorSpaceFamily objects.
On top of this also sit a breakage on how ColorSpaces are created. Two
methods are now offered: one only providing construction of no-argument
color spaces (and thus taking a simple name), and another taking an
ArrayObject, hence used to create ColorSpaces requiring arguments.
Finally, on top of *that* two ways to get a color space in the Renderer
are made available: the first creates a ColorSpace with a name and a
Resources dictionary, and another takes an Object. These model the two
addressing modes described above.
This ensures the value goes through the regular ToPrimitive mechanism,
which PropertyKey::from_value() bypasses. This is relevant for objects
with a @@toPrimitive method, for example.
Also enables one skipped test in delete-basic.js, which now passes.
This is not in the spec and does pointless work:
- If either of them is true, we would determine the same result with the
manual code point iteration and comparison
- If neither of them is true, we iterate from the start again and repeat
the work that was just done
Instead, only have the manual loop from the spec and do a length
comparison at the end.
Removing it brings the following microbenchmark from ~5.5s down to ~3.5s
on my machine:
```js
const a = "x".repeat(100_000_000) + "a";
const b = "x".repeat(100_000_000) + "b";
a < b
```
Discord modals/pop-outs are in a "layerContainer" <div> with
`z-index: 1002`, which then has an immediate child <div> called
"positionLayer" with `z-index: 0`. We only ever hit test child stacking
contexts with z-index set to anything but 0 (step 7 and step 1 of the
hit test), but not for exactly 0 (step 6). This made it impossible to
hit any element inside positionLayer, making pop-ups such as the emojis
and GIFs unusable.
Instead of creating a new global object and proxying everything through
it, we now evaluate console inputs inside a `with` environment.
This seems to match the behavior of WebKit and Gecko in my basic
testing, and removes the ConsoleGlobalObject which has been a source of
confusion and invalid downcasts.
The globals now live in a class called ConsoleGlobalObjectExtensions
(renamed from ConsoleGlobalObject since it's no longer a global object).
To make this possible, I had to add a way to override the initial
lexical environment when calling JS::Interpreter::run(). This is plumbed
via Web::HTML::ClassicScript::run().
- Wrapped sequence should be inserted before first non-match
node instead of next sibling of first non-match node
- If sequence is not empty after sibling traversal it should be
wrapped
This change makes outer min-content width and outer max-content
width for cells to be calculated in the way specifed in the spec:
- The outer min-content width of a table-cell is max(min-width,
min-content width) adjusted by the cell intrinsic offsets.
- The outer max-content width of a table-cell in a non-constrained
column is max(min-width, width, min-content width, min(max-width,
max-content width)) adjusted by the cell intrinsic offsets.
- The outer max-content width of a table-cell in a constrained
column is max(min-width, width, min-content width, min(max-width,
width)) adjusted by the cell intrinsic offsets.
Vectors that stick around in the AST were wasting a fair bit of memory
due to the growth padding we keep by default. This patch goes after some
of these vectors with the shrink_to_fit() stick to reduce waste.
Since the AST can stay around for a long time, it is worth making an
effort to shrink it down when we have a chance.
After setting up all the bindings in function_declaration_instantiation,
we now ask DeclarativeEnvironment to do a shrink_to_fit() on its vector
of bindings.
This ends up saving 5.6 MiB on twitter.com/awesomekling :^)
Instead of CallExpression storing its arguments in a Vector<Argument>,
we now custom-allocate the memory slot for CallExpression (and its
subclass NewExpression) so that it fits both CallExpression and its list
of Arguments in one allocation.
This reduces memory usage on twitter.com/awesomekling by 8.8 MiB :^)
This template allows us to allocate an AST node and an array of some
arbitrary type T with one allocation instead of two. This can save
a lot of memory in some cases.
Thanks to Jonathan Müller for suggesting this technique! :^)
