Obtained by running:
convert rgb_components.jpg -colorspace cmyk \
-sampling-factor 1 ycck-1111.jpg
convert rgb_components.jpg -colorspace cmyk \
-sampling-factor 2 ycck-2111.jpg
convert rgb_components.jpg -colorspace cmyk ycck-2112.jpg
where rgb_components.jpg is the file in Tests/LibGfx/test-inputs/jpg.
(I used the web version of `convert` at
https://cancerberosgx.github.io/magic/playground/index.html)
While this does indeed produce a cmyk jpg (using the YCCK encoding
internally), it uses the mathematical rgb->cmyk conversion and does
not embed an cmyk color space in the output jpg.
Normally, cmyk images are for printing and hence converting them
from cmyk to rgb using a color profile like SWOP leads to better
results. So if a cmyk image does not contain color space information,
applications might use something like SWOP instead of the simple
math transform to convert to RGB. Programs doing that will show
these images as fairly muted (and would arguably be correct doing
so).
Hence, tests using these images shouldn't check their RGB values.
Ideally, we'd add a way to get the raw cmyk data from a cmyk jpeg,
and then tests could test color values against that.
The -1111 image uses no subsampling, meaning each channel's sampling
factor is 1.
The -2111 image uses subsampling for the non-Y channels, meaning the
sampling factors are 2 for Y and 1 each for YYK.
The -2112 image uses subsampling for the two C channels, meaning the
sampling factors are 2 for Y and K and 1 each for YY.
We correctly render the -1111 variant (using e.g.
`Build/lagom/bin/image -o out.png .../ycck-1111.jpg).
We render the -2111 variant, but it looks pretty broken.
We refuse to decode the -2112 variant. This is #21259.
Manual tests for now, but having these in tree will make it easier
to write unit tests later, once things work better.
This adds a simple EHCI driver that currently only interrogates the
device and checks if all ports are addressable via associated legacy
controllers (companion controllers), and warns if this is not the case.
This also adds a lot of the other data structures needed for actually
driving the controller, but these are currently not hooked up to
anything.
To test this run with `SERENITY_EXTRA_QEMU_ARGS="--device usb-ehci"`
or the q35 machine type
Still try parsing the now gone "-audio-help" output first, then attempt
the new "-audiodev help" if stdout was empty. This fixes support for
QEMU 8.2+ audio since "-audio-help" is now an invalid option.
The BatchingDispatcher mechanism is used by HTMLImageElement to avoid
decoding one image at a time, since interleaving decode/layout/repaint
over and over takes way more time than doing many decodes followed by
a single layout/repaint pair.
Before this change, we didn't have a limit on how many batched loads
we'd allow ourselves to queue up, which could lead to situations where
more and more images kept being added to the queue, and never getting
processed.
This fixes the issue by putting an arbitrary limit (16) on the number
of batched image loads, and then allowing the flush to happen after
that instead of re-deferring processing.
If an image element has no alt attribute, other browsers don't fall back
to using the src attribute like we did.
This gave us a janky look while loading pages that other browsers don't
have, and it's not like seeing a partial URL is really helpful to the
user anyway.
In: https://tc39.es/ecma262/#sec-%typedarray%-intrinsic-object
The spec says:
> is a constructor function object that all of the TypedArray
> constructor objects inherit from.
From what I understand from this, it effectively just means is that the
prototype for the constructor should simply be set to
TypedArrayConstructor. We _were_ doing that, but also inheriting from
it in C++.
This meant we were invoking TypedArrayConstructor::initialize for each
of the typed arrays. This is not actually what we want, since it means
that the 'of' and 'from' functions were being defined as native
properties in both the concrete typed array (e.g Uint8Array), and the
abstract TypedArray. Instead, the properties should only be defined and
inherited from the abstract TypedArray class.
Diff Tests:
+4 ✅ -4 ❌
Co-Authored-By: Andreas Kling <kling@serenityos.org>
Instead, we now pass String if we have one. In particular, this fixes an
issue where image elements with a data: URL src would copy the entire
URL string every time we painted (before the image had been decoded).
This was very noticeable on "fully downloaded" web pages where every
single image has been turned into a data: URL.
This code didn't account for position:fixed elements, which meant that
we'd swallow repaints for such elements when the viewport wasn't
scrolled to the top of the page.
We replace the incomplete optimization with a FIXME noting that this
needs to be handled correctly when reintroduced.
Per:
https://dom.spec.whatwg.org/#concept-reflect
We should be calling `get_attribute_value` for reflected IDL strings.
No functional change as nowhere is performing a reflect on a nullable
type, and just ends up simplifying the code.
This is a cleanup patch, moves a chunk of repeated code to one place
instead of assigning variables with the same values twice in two
different places of code.
Currently if users select last bytes in HexEditor with mouse in either
Hex or Text mode, they will be able to move cursor on the byte outside
bounds. If then they try to write something in either of those modes,
app will crash.
This patch moves the recently added "replace" cursor to always be on the
last byte of the selection instead of being on the byte after the last
selected byte.
This patch changes cursor type from caret to black box for both Hex and
Text modes, because right now the way how blinking caret looks like is
more closer to "insert" mode in similar editors, whereas the real
behavior of this cursor is more of a "replace" mode seen in similar
editors like GHex.
This stopped being called for anything without a navigable container
after 76a97d8, due to the early return. This broke SVG <use> elements
that reference elements defined later in the document.
This should allow us to eventually properly saturate high-bandwidth
network links when using TCP, once other nonoptimal parts of our
network stack are improved.
Instead of lying and claiming we always have space left in our receive
buffer, actually report the available space.
While this doesn't really affect network-bound workloads, it makes a
world of difference in cpu/disk-bound ones, like git clones. Resulting
in a considerable speed-up, and in some cases making them work at all.
(instead of the sender side hanging up the connection due to timeouts)
