Calculate a "preferred aspect ratio" based on the value of
`aspect-ratio` and the presence of a natural aspect ratio, and use that
in layout.
This is by no means complete or perfect, but we do now apply the given
aspect-ratio to things.
The spec is a bit vague, just saying to calculate sizes for
aspect-ratio'ed boxes the same as you would for replaced elements. My
naive solution here is to find everywhere we were checking for a
ReplacedBox, and then also accept a regular Box with a preferred aspect
ratio. This gets us pretty far. :^)
https://www.w3.org/TR/css-sizing-4/#aspect-ratio-minimum is not at all
implemented.
These are superseded by headless-browser running these tests in a single
process, and aren't used by CI anymore. It's a bit confusing having them
still around so let's be rid of them.
I opened smolkling.webp in Photoshop, added a layer mask with a vertical
gradient, replaced the leftmost column with completely transparent
pixels (because the leftmost column is vertically predicted with the
horizontal filter too), and saved it as webp. That wasn't enough to
get a horizontal filter for the ALPH chunk though, so I also ran
cwebp \
-alpha_filter best \
smolkling.webp \
-o Tests/LibGfx/test-inputs/smolkling-vertical-alpha.webp
That did the trick.
I opened smolkling.webp in Photoshop, added a layer mask, and
scribbled a shape vaguely looking like the letter "C" on it.
I then saved it as a lossy webp and that was enough to end up
with filter method ¯\_(ツ)_/¯
I opened smolkling.webp in Photoshop, added a layer mask with a
horizontal gradient, and saved it as webp. That wasn't enough to
get a horizontal filter for the ALPH chunk though, so I also ran
cwebp \
-alpha_filter best \
smolkling-ps.webp \
-o Tests/LibGfx/test-inputs/smolkling-horizontal-alpha.webp
That did the trick.
(Looks like doing the same with a vertical or diagonal gradient
_also_ produces a webp file with filtering_method 1, i.e. horizontal.)
Prior to this commit, PropertyOwningCSSStyleDeclaration::serialized()
did not include custom properties, which lead to an incomplete
`cssRule.cssText` result.
This commit makes that class also serialize the custom properties and
place them before the regular properties in the rule text.
On macOS, CMake incorrectly tries to add and/or remove rpaths from files
that it has already processed when it performs installation. Setting the
rpaths during the build process ensures that they are only set once, and
as a bonus, makes installation slightly more performant.
Fixes#10055.
We were incorrectly returning a "specified size suggestion" for flex
items with a definite main size where that main size was also automatic.
This led to us incorrectly choosing 0 as the automatic minimum size for
that flex item, instead of its min-content size.
Generated iterator prototypes already have the IteratorPrototype as
their prototype, but we were incorrectly hijacking them and rerouting
to ObjectPrototype.
Regressed in cfe663435e.
The main differences between our current implementation and the spec
are:
* The title element need not be a child of the head element.
* If the title element does not exist, the default value should be
the empty string - we currently return a null string.
* We've since added AOs for several of the spec steps here, so we
do not need to implement those steps inline.
Adds a second pass to resolve percentage paddings and margins of grid
items after track sizes are known. If resolving percentage paddings
or margins affects tracks sizes then second pass to re-resolve track
sizes might also be needed but I cannot come up with an example to
reproduce that so we can leave it to improve in the future :)
This fixes the issue when functions that distribute base_size
or growth_limit to tracks only considered *affected* spanned tracks
while calculating left extra that is available for distribution while
indeed it should be just *all* spanned track by specific item that
extra space size.
This fixes the issue that currently we use "auto" as initial value for
grid-template-column and grid-template-rows although spec says it
should be "none". This makes a lot of difference for these properties
because currently we represent "auto" as a list with one auto-sized
track which means initial value for grid-template-column defines one
"explicit" track while it should define none of them.
This change makes grid-auto-columns/rows be applied to the correct
tracks when initial values is used for grid-template-column/rows.
This changes grid items position storage type from unsigned to signed
integer so it can represent negative offsets and also updates placement
for grid items with specified column to correctly handle negative
offsets.
Depending on stack values being correctly and deterministically
overwritten was a bit too optimistic, to be honest. This new logic uses
a value on the heap.
Dr. POSIX says:
Although the space used by string is no longer used once a new
string which defines name is passed to putenv(), if any thread in
the application has used getenv() to retrieve a pointer to this
variable, it should not be freed by calling free(). If the changed
environment variable is one known by the system (such as the locale
environment variables) the application should never free the buffer
used by earlier calls to putenv() for the same variable.
Applications _should_ not free the data passed to `putenv`, but they
_could_ in practice. I found that our Quake II port misbehaves in this
way, but does not crash on other platforms because glibc/musl `putenv`
does not assume that environment variables are correctly formatted.
The new behavior ignores environment variables without a '=' present,
and prevents excessively reading beyond the variable's name if the data
pointed to by the environment entry does not contain any null bytes.
With this change, our Quake II port no longer crashes when switching
from fullscreen to windowed mode.
This fixes an issue where images with padding and/or border did not have
their size adjusted for `border-box`, thereby becoming larger than
intended by the author.
I was not aware of this framework back when implementing this back in
bc54560e59. Add in some basic tests for
this now that we are compliant with the specification.
If a box has a negative margin-left, it may have a negative effective
offset within its parent BFC root coordinate system.
We can account for this when calculating the amount of left-side float
intrusion by flooring the X offset at 0.
Now that we have a way to resolve calc() lengths without a layout node,
we can finally support calc() values in font-size.
This wasn't possible before because font-related properties have to be
resolved eagerly in StyleComputer due to font-relative CSS length units
depending on the computed font being known.
Use contains_percentage() that works for calc() values instead of
is_percentage().
This fixes issue when tracks with calc() that has percentages where
considered as "fixed" tracks with resolvable size which led to
incorrectly resolved infinite final track sizes.
This reintroduces bounds-checking for the CSS `<angle>`, `<frequency>`,
`<integer>`, `<length>`, `<number>`, `<percentage>`, `<resolution>`,
and `<time>` types.
I regressed this around 6b8f484114 when
changing how we parsed StyleValues.
This is an improvement from before though, since we now allow the bounds
of a dimension type to have units.
Added a test to make sure we don't regress this again. :^)
If a flex item's main size is a CSS calc() value that resolves to a
length and contains a percentage, we can only resolve it when we have
the corresponding reference size for the containing block.
Previously, we would always respect the `text-align` property, even if
the text being aligned was too long for its line box and would be
clipped. This led to seeing the clipped middle/end of strings when we
should instead always see the beginning of the text.
In AArch CI, this test alone takes up 110.6 seconds. In x86_64 CI, it
takes up 68.4 seconds. There is no reason to spend this much time and
this many trials on this.
Let's reduce the number of iterations to 500. This should still surface
any misalignment with high probability, and should speed up the CI time
from minutes to seconds.
This is a hack to emulate the behavior of other engines that use
fixed-point math. By rounding to 3 decimals, we retain a fair amount of
detail, while still allowing overshooting 100% without breaking lines.
This is both gross and slow, but it fixes real sites. Notably, the
popular Bootstrap library uses overshooting percentages in their
12-column grid system.
This hack can be removed when CSSPixels is made a fixed-point type.
If the flex container is being sized under a max-content main size
constraint, there is effectively infinite space available for flex
items. Thus, flex lines should be allowed to be infinitely long.
This is a little awkward, because the spec doesn't mention specifics
about how to resolve flexible lengths during intrninsic sizing.
I've marked the spec deviations with big "AD-HOC" comments.
Instead of just measuring the layout viewport, we now measure overflow
in every box that is a scroll container.
This has the side effect of no longer creating paintables for layout
boxes that didn't participate in layout. (For example, empty/anonymous
boxes that were ignored by flex itemization.)
Such boxes are now marked as "(not painted)" in the layout tree dumps,
as they have no paintable to dump geometry from.
This is not a beautiful program, but it does allow you to regenerate
the baseline expectation for a given layout or text test with a single
command. :^)
Each secondary partition has an independent BooleanDecoder.
Their bitstreams interleave per macroblock row, that is the first
macroblock row is read from the first decoder, the second from the
second, ..., until it wraps around again.
All partitions share a single prediction state though: The second
macroblock row (which reads coefficients off the second decoder) is
predicted using the result of decoding the frist macroblock row (which
reads coefficients off the first decoder).
So if I understand things right, in theory the coefficient reading could
be parallelized, but prediction can't be. (IDCT can also be
parallelized, but that's true with just a single partition too.)
I created the test image by running
examples/cwebp -low_memory -partitions 3 -o foo.webp \
~/src/serenity/Tests/LibGfx/test-inputs/4.webp
using a cwebp hacked up as described in #19149. Since creating
multi-partition lossy webps requires hacking up `cwebp`, they're likely
very rare in practice. (But maybe other programs using the libwebp API
create them.)
Fixes#19149.
With this, webp lossy support is complete (*) :^)
And with that, webp support is complete: Lossless, lossy, lossy with
alpha, animated lossless, animated lossy, animated lossy with alpha all
work.
(*: Loop filtering isn't implemented yet, which has a minor visual
effect on the output. But it's only visible when carefully comparing
a webp decoded without loop filtering to the same decoded with it.
But it's technically a part of the spec that's still missing.
The upsampling of UV in the YUV->RGB code is also low-quality. This
produces somewhat visible banding in practice in some images (e.g.
in the fire breather's face in 5.webp), so we should probably improve
that at some point. Our JPG decoder has the same issue.)
I somehow added the wrong image here. 4.webp is the one described
by the comment in the test. Now test actually uses the image it
claims to use.
No behavior change.
Previously this was compiled to require an object despite the IDL file
specifying 'optional'.
This commit makes IDLGenerator respect this modifier, and fixes the only
affected instance.
