This makes them cheap to move around, since we can store them in a
NonnullOwnPtr instead of memcopying 2584(!) bytes.
Drastically reduces the chance of stack overflow while building the
layout tree for deeply nested DOMs (since tree building was putting
these things on the stack).
This change also exposed a completely unnecessary ComputedValues deep
copy in block layout.
We don't currently calculate the fill- or stroke-boxes of SVG elements,
so for now we use the content- and border-boxes respectively, as those
are the closest equivalents. The test will need updating when we do
support them.
Also, the test is a screenshot because of rendering differences when
applying transforms: a 20px box does not get painted the same as a 10px
box scaled up 2x. Otherwise that would be the more ideal form of test.
LibSQL still uses ByteString internally for storage, but to help outside
application port to String, add helpers to construct values from String
and to convert a value to a String.
We don't need to forward Cookie-related IPCs from the WebView through
the Tab to the BrowserWindow. We can skip the Tab like we do in other
chromes.
This is primarily to reduce overhead when changing Cookie IPCs in future
patches.
These are written by `mutool extract` for CMYK images.
They don't contain color profiles so they're not super convenient.
But `image` can convert them (*) to sRGB as long as you use it with
`--assign-color-profile` pointing to some CMYK icc profile of your
choice.
*: Once #22922 is merged.
.pam is a "portrable arbitrarymap" as documented at
https://netpbm.sourceforge.net/doc/pam.html
It's very similar to .pbm, .pgm, and .ppm, so this uses the
PortableImageMapLoader framework. The header is slightly different,
so this has a custom header parsing function.
Also, .pam only exixts in binary form, so the ascii form support
becomes optional.
This change introduces a method for direct access to the paintable of
a PaintableFragment. This method is intended to replace the usage of
the layout node pointer. Currently, we are only eliminating the use
of `layout_node()` in hit testing.
Additionally, we no longer check if a fragment's layout node is a
`BlockContainer` before recursing into its children during hit testing.
This check was likely relevant when all fragments were owned by
`PaintableWithLines`, but now it should be safe to remove this check.
It converts from a CMYKBitmap to an (rgb) bitmap, using a real
color profile.
The API design here isn't super scalable (what if we want to also
handle grayscale inputs? What if we also want to convert _to_ cmyk
or grayscale?), but we have to start somewhere. Uses of this can
inform future API improvements.
Every single of images's functions then go ahead and error out on
CMYKBitmaps for now.
(Alternatively, we could make them the low-quality CMYK->RGB
conversion that previously happened implicitly, but let's go
with this for now.)
(With this structure, we could also do something smarter for
Vector images in the future.)
Here's how this looks:
% Build/lagom/bin/image \
-o out.png Tests/LibGfx/test-inputs/jpg/ycck-2111.jpg
Runtime error: Can't save CMYK bitmaps yet, convert to RGB first
with --convert-to-color-profile
% Build/lagom/bin/image \
--convert-to-color-profile serenity-sRGB.icc \
-o out.png Tests/LibGfx/test-inputs/jpg/ycck-2111.jpg
Runtime error: No source color space embedded in image.
Pass one with --assign-color-profile.
% Build/lagom/bin/image \
--assign-color-profile path/to/CMYK/USWebCoatedSWOP.icc \
--convert-to-color-profile serenity-sRGB.icc \
-o out.png Tests/LibGfx/test-inputs/jpg/ycck-2111.jpg
Runtime error: Psych, can't convert CMYK bitmaps yet either
As usual, serenity-sRGB.icc is from
`Build/lagom/bin/icc -n sRGB --reencode-to serenity-sRGB.icc` and
the adobe cmyk profiles are available at
https://www.adobe.com/support/downloads/iccprofiles/iccprofiles_win.html
which ultimately leads to:
https://download.adobe.com/pub/adobe/iccprofiles/win/AdobeICCProfilesCS4Win_end-user.zip
This makes it easier to move the color space conversion code out
into a helper function, and will be used to pass around CMYK bitmaps.
No behavior change.
...instead of warn() + manual return.
Before:
% Build/lagom/bin/image -o out.asdf in.png
can only write .bmp, .png, .ppm, and .qoi
Now:
% Build/lagom/bin/image -o out.asdf in.png
Runtime error: can only write .bmp, .png, .ppm, and .qoi
That doesn't look worse, and it's less code (and makes moving the
code into helper functions easier).
Before this change, it was possible for flex lines with negative
remaining space (due to overflowing items) to put a negative amount
of space between items for some values of `justify-content`.
This makes https://polar.sh/SerenityOS look much better :^)
The -p flag is equivalent to the previous behavior: outputting the
uptime in a human-readable form.
We don't seem to expose the number of online users or the load averages,
so those sections are missing from the output compared to those OSes.
This attribute has some compatbility issues...
- The spec says it should be an SVGAnimatedRect which contains
a DOMRect and a DOMReadOnlyRect.
- Blink gives you an SVGAnimatedRect with 2x SVGRect
- Gecko gives you an SVGAnimatedRect with 2x SVGRect? (nullable)
I ended up with something similar to Gecko, an SVGAnimatedRect
with 2x DOMRect? (nullable)
With this fixed, we can now load https://polar.sh/ :^)
As of commit ccd701809f, the formatter for
JsonValue now fully serializes the value. The serializer will surround
the string value with quotes. We want control over when we add quotes to
the generated Inspector HTML, so avoid formatting attributes as raw JSON
values.
This works by defining a set of weak symbols in dynamic linker whose
value would be provided by it. This has the same effect as preloading
library that magically knows right addresses of functions shared between
dynamic linker and LibC.
We were previously passing the same information by rewriting values
based on hardcoded library name, so the new approach seems a little
nicer to me.
When decoding a CMYK image and asked for a normal `frame()`, the decoder
would convert the CMYK bitmap into an RGB bitmap. Calling `cmyk_frame()`
after that point will provoke a null-dereference.
The only downside is we are limited to 4 recent projects now. LibGUI
currently relies on the number of recent files being constexpr, so that
will take some more work to make it variable.
We previously assumed that `set_most_recently_open_file()` would only be
called after `Menu::add_recent_files_list()` had been called, and would
crash if we hadn't called it yet. This stops the crash. We're fine to
do this, because we always call `update_recent_file_actions()` in
`register_recent_file_actions()` so it's guaranteed to be up to date
when we do need it.
A couple of tweaks here to make it work better:
- Call `set_cursor_and_focus_line()` to make the Editor scroll to the
symbol's location.
- Remove focus from the Locator's text box so your cursor jumps to the
Editor instead of staying in the Locator.
This being a Popup window meant it behaved in a couple of janky ways:
- It would steal the focus each time it was shown, so after every key
press in the TextBox.
- It would disappear when you focused that TextBox again.
Using the Autocomplete window type fixes both of these. While the
Locator is not technically an autocomplete, it shares the general "type
and get suggestions based on the input, which you can select" behavior,
so this is close enough.
Also change a Vector<Handle> to a Vector<NonnullGCPtr> while we're
here, since there's no need to use handles for members of a cell.
Fixes an ASAN error on the HTML/Window-postMessage.html test.
We should be using WebIDL Promise in these methods, per the spec
references in other specifications. That is, the HTML spec always links
to WebIDL when it talks about `Promise<T>`. The Crypto seems to be
missing those cross-references.
While we're here, actually resolve the digest promise in parallel.
Previously, our code for the fixup of table rows assumed that missing
cells in a table row must be sequential. This may not be true if the
table contains cells have a rowspan greater than one.
We now split up symbols into zero-sized symbols that label single
instructions (no need to separate them by newlines; they are used for
jump labels and relocation targets within a larger block of code) and
ranged symbols that label functions. Empty symbols are discarded since
at least RISC-V ELF files contain quite a few of those. Zero-sized
symbols and ranged symbols are handled almost the same, but this way we
can make sure that zero-sized symbols don't interfere with ranged
symbol's newline separation logic. For zero-sized symbols, the "symbol
contains address" logic is updated so they actually contain the one
address they're pointing at, fixing the bug with many "dangling"
zero-sized symbols after a function that contained them. Zero-sized
labels are also no longer printed as a start-end range, since that is
unnecessary visual noise.
We previously were considering Float and Doubles as non-supported types.
But this was done in a sneaky way, by letting them hit the default case
in the `read_type` method. So, when I ported this function to the
generator we started to make this types flow into the system without a
proper support there. Since 3124c161, we would have crashes on images
containing tags with a floating point value.
A lot of images format use Exif to store there metadata. As Exif is
based on the TIFF structure, the TIFF decoder can, without modification
be able to decode the metadata. We only need a new API to explicitly
mention that we only need the metadata.
Support for JPEGs embedded in TIFF images was introduced with TIFF 6.0.
However, this implementation had major issues. It was so problematic
that they decided to reimplement it from scratch in 1995, three years
later. The two incarnations are obviously incompatible.
For more details see:
https://www.awaresystems.be/imaging/tiff/specification/TIFFTechNote2.txt
When present, the alpha channel is also affected by the horizontal
differencing predictor.
The test case was generated with GIMP with the following steps:
- Open an RGB image
- Add a transparency layer
- Export as TIFF with the LZW compression scheme
Remove all functions with platform #if's from fenv, and
add arch dependent implementations instead. The build
system now selects the implementation based on the platform.
Doesn't matter if both profiles are sRGB since
inv(A) * A == A * inv(A), but when converting e.g. a P3 image to
sRGB, the colors are very off if the matrices are the wrong way round
here.
perform_call() wants a ReadonlySpan<Value>, so just grab a slice of the
current register window instead of making a MarkedVector.
10% speed-up on this function call microbenchmark:
function callee(a, b, c) { }
function caller(callee) {
for (let i = 0; i < 10_000_000; ++i)
callee(1, 2, 3)
}
caller(callee)
This is an option supported by coreutils, so we might as well support
it too.
It allows users to wrap their encoded output after the "column" value
they provide.
This commit also has the Markdown look more like what we see
when running ArgsParser::print_usage_markdown() (and it fixes some
of the examples).
Value::Value(double) already converts double to int when it is safe, no
need to check for this here explicitly. While this technically removes
an optimization, I doubt that it will regress performance in any
measurable way.
This method (unlike can_read_line) ensures that the delimiter is present
in the buffer, and doesn't return true after eof when the delimiter is
absent.
For parameters that exist strictly as "locals", we can save time and
space by not adding them to the function environment.
This is a speed-up across the board on basically every test.
For example, ~11% on Octane/typescript.js :^)
Spec defines `[LegacyNullToEmptyString]` on `value` argument of
`setProperty` but since `internal_set` calls `setProperty` directly
instead of using IDL generated binding, we need to make sure that null
is treated as empty string.
Fixes items grid loading on https://d.rsms.me/stuff/
