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.
Separating the paths for replaced and non-replaced floating boxes lost
the logic for margin, padding and border which was done by
compute_width_for_floating_box. Set them the same way as we do for
block-level replaced elements, per the specification.
The alpha channel of a lossy webp is always stored separately from
the (lossy) RGB data. Alpha is either compressed in a lossless webp
that stores just the alpha data, or it's stored completely
uncompressed. (But again, even if it's compressed, it's losslessly
compressed.)
This adds a test for uncompressed alpha, which I hadn't tested before.
It seems to work correctly, though :^)
I generated the test image by running:
~/Downloads/libwebp-1.3.0-mac-arm64/bin/cwebp \
-alpha_method 0 \
Tests/LibGfx/test-inputs/extended-lossless.webp \
-o Tests/LibGfx/test-inputs/extended-lossy-uncompressed-alpha.webp
This image covers two things that aren't covered by the existing
tests, and I found it useful for testing locally. The image's license
allows redistributing it, so add it as a test case.
Since there are no table-specific boxes anymore it would be nice to
output their types additionally in layout dump so we can tell table
boxes from "regular" boxes.
Solves conflict in layout tree "type system" when elements <label> (or
<button>) can't have `display: table` because Box can't be
Layout::Label (or Layout::ButtonBox) and Layout::TableBox at the same
time.
From spec https://drafts.csswg.org/css-grid/#grid-items:
"Each in-flow child of a grid container becomes a grid item, and each
child text sequence is wrapped in an anonymous block container grid
item."
Fixes the problem that text sequences inside grid containers are
ignored and not displayed.
Fixes the bug that currently we always consider tracks with percentage
size as ones with "fixed" length even when available size is not
definite. With this change tracks with percentage size when available
size is not definite will be considered as "intrinsic" sized.
We were not taking reverse flex directions into account when choosing
the initial offset for flex item placement if justify-content were
either space-around or space-between.
Although we translate e.g `block` to `block flow` for internal use in
the engine, CSS-DISPLAY-3 tells us to use the short form in
serializations for compatibility reasons.
This adds 9 points to our score on https://html5test.com/ :^)
This allows us to create "text tests" in addition to "layout tests".
Text tests work the same as layout tests, but dump the document content
as text and exit upon receiving the window "load" event.
It does not make sense to test known-working code that is deprecated and
in the process of being removed. Also, this test becomes too cumbersome
to write without using read_all or line iteration in some form, and
migrating the test is just silly.
Introduces incomplete parsing of grid shorthand property. Only
<grid-template> part of syntax is supported for now but it is enough
to significantly improve rendering of websites that use this shorthand
to define grid :)
