| Age | Commit message (Collapse) | Author |
|---|
|
|
|
Somewhere the path bounding box in the layout and the actual draw path
are getting slightly mismatched. This results in partly clipped bits of
SVGs. The paths are already clipped to the containing SVG, and the size
of the path in the layout is computed from the bounding box, so it is
probably safe just to remove this clipping for now.
|
|
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.
|
|
A reference to the current stack frame becomes invalid after returning,
so returning Bytes is pointless.
I don't understand why this wasn't discovered earlier, but it caused
some CI problems for me, so I fixed it.
Don't take this as encouragement to break master! :^)
|
|
|
|
We have double precision in the parser, and currently use doubles for
most of layout, so we might as well keep that extra precision inside
NumberStyleValue too.
|
|
Use IntegerStyleValue where we should; remove the ability of
NumberStyleValue to hold integers, and add integer interpolation for
animations.
|
|
Having one StyleValue for `<number>` and `<integer>` is making user code
more complicated than it needs to be. We know based on the property
being parsed, whether it wants a `<number>` or an `<integer>`, so we
can use separate StyleValue types for these.
|
|
This is in preparation of splitting off a separate IntegerStyleValue.
|
|
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.
|
|
The spec doesn't talk about this happening in the text, but
`dequant_init()` in 20.4 processes segment adjustment and quantization
index adjustment in the same variable `q` before clamping.
Since we had to adjust the latter step in the previous commit, do
it for the former step too.
I haven't seen this happen in the wild yet (and now, I hopefully
never will notice it if it happens).
|
|
The spec doesn't talk about this happening in the text, but
`dequant_init()` in 20.4 stores `q` in an int and clamps that
to 0 later.
|
|
It's up to callers of the ImageDecoderPlugin to honor loop_count().
The ImageDecoderPlugin doesn't have to look at it when decoding frames.
No behavior change.
|
|
The spec says that the AC dequantization factor for Y2 data should
be at least 8, so do that.
This only has a very small effect (only the first two AC table
entries are < 8 after multiplying with 155 / 100, so this would
have only a small effect on brightness), and this case is hit
exactly 0 times in all my test images. But it's still good to match
the spec.
|
|
No behavior change.
|
|
For a 1024x1024 image, saves about a quarter MB of memory use while
decoding (compared to the decompressed image data itself needing
4 MiB). Not a huge win, but also very easy to do, so might as well.
No behavior change, no measurable performance impact.
|
|
No functional or performance changes; they were probably already
optimized away by the compiler.
|
|
I could not discover proof that this is actually faster than the non-SSE
version. In addition, for these relatively simple structures, the
compiler is often sufficiently smart to generate SSE code itself.
For a synthetic font benchmark I wrote, this results in a nice 11%
decrease in runtime.
|
|
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.
|
|
We were only clipping for hidden, when we should be clipping for hidden,
clip, scroll and auto. Basically everything but visible. :^)
|
|
This will allow us to have a shared code path for overflow calculation.
|
|
|
|
For some reason, we were decoding the source color twice for every pixel
in the inner-most loop of `blit_filtered`. This makes sure we only
decode the source color once, and rearranges the code to improve
readability.
For my synthetic font rendering benchmark, this improves glyph rendering
performance by ~9%.
|
|
Now that we allocate an oversized backing store during resizing of the
viewport, we need to constrain the source rect used when drawing a
scaled version of the content in the special mode used by Presenter.
Regressed with 85c542ab009ca7aea95f7a7503990c26ed27a123.
|
|
When the background color has an alpha < 255, we can't copy over the
pixel alpha.
|
|
This is used on GitHub and many other websites.
|
|
|
|
Similarly, ignore STT_SECTION symbols, which show up as the empty
string.
This change makes AArch64 backtraces symbolicate correctly.
|
|
This ensures that we stop walking the stack at `_entry` and don't
crash/panic when computing backtraces.
|
|
This ensures that the RAM does not fill up with already processed
coredumps when many tests crash (as is the case on AArch64). We only
do this in self-test mode so as to avoid racing CrashDaemon.
|
|
|
|
We already clamp these values to zero, so it's actually pretty harmless
when this happens. If someone wants to investigate these issues deeper
and see if they can be fixed earlier in the layout pipeline, they can
enable the spam locally.
|
|
The textContent setter changes the structure of the DOM, therefore the
layout tree becomes invalid.
|
|
We had support for going to a specific line before, but now we support
jumping around using the `line:column` format :^)
|
|
for_each_line_segment_on_elliptical_arc() flips the start/end points
for negative theta deltas. When doing this we have to make sure the
line segments emitted swap the start/end points back, so that the
(correct) winding order can be calculated from them.
This makes nonzero fills not totally broken for a lot of SVGs.
|
|
This is an implementation of the scanline edge-flag algorithm for
antialiased path filling described here:
https://mlab.taik.fi/~kkallio/antialiasing/EdgeFlagAA.pdf
The initial implementation does not try to implement every possible
optimization in favour of keeping things simple. However, it does
support:
- Both evenodd and nonzero fill rules
- Applying paint styles/gradients
- A range of samples per pixel (8, 16, 32)
- Very nice antialiasing :^)
This replaces the previous path filling code, that only really applied
antialiasing in the x-axis.
There's some very nice improvements around the web with this change,
especially for small icons. Strokes are still a bit wonky, as they don't
yet use this rasterizer, but I think it should be possible to convert
them to do so.
|
|
It's a pain (and silly) to make this private and add every user as a
friend.
|
|
The glyph bitmap is a grayscale image that is multiplied with the
requested color provided to `Gfx::Painter::draw_glyph()` to get the
final glyph bitmap that can be blitted.
Using `Gfx::Color::multiply()` is unnecessary however: by simply taking
the destination color and copying over the glyph bitmap's alpha value,
we can prevent four multiplications and divisions per pixel.
In an artifical benchmark I wrote, this improved glyph rendering
performance by ~9%.
|
|
This is safe because:
* prediction only computes averages, or explicitly clamps for
TM_PRED / B_TM_PRED. Since the inputs are in [0, 255], so will the
outputs.
* Addition of IDCT and prediction buffer is immediately clamped back
to [0, 255]
No behavior change, and matches what both libwebp and the reference
implementation in rfc6386 do.
|
|
https://datatracker.ietf.org/doc/html/rfc6386#section-14.5 says:
"""
The summing procedure is fairly straightforward, having only a couple
of details. The prediction and residue buffers are both arrays of
16-bit signed integers. Each individual (Y, U, and V pixel) result
is calculated first as a 32-bit sum of the prediction and residue,
and is then saturated to 8-bit unsigned range (using, say, the
clamp255 function defined above) before being stored as an 8-bit
unsigned pixel value.
"""
It's IMHO not 100% clear if the clamping is supposed to happen
immediately (so that it affects prediction inputs for the next
macroblock) or later.
But vp8_dixie_idct_add() on page 173 in
https://datatracker.ietf.org/doc/html/rfc6386#section-20.8 does:
recon[0] = CLAMP_255(predict[0] + ((a1 + d1 + 4) >> 3));
So it does look like it should happen immediately.
(I'm a bit confused why the spec then says "The prediction and residue
buffers are both arrays of 16-bit signed integers", since the
prediction buffer can just be an u8 buffer now, without changing
behavior.
|
|
I accidentally inserted a bunch of code in between.
No behavior change.
|
|
Without it, KeyboardMapper crashes as soon as you try to open a file.
|
|
This is quite straightforward with our new RIFF infrastructure.
|
|
With this, the WAV loader is a completely modern LibAudio loader:
- Own type header for RIFF data structures
- custom stream read functions for the types
- Final removal of legacy I/O error checking
- clearer error messages
- clean handling of header chunks
The latter will allow proper handling of other chunks (before "data") in
the future, such as metadata :^)
|
|
The spec has that clamp at the end of
https://datatracker.ietf.org/doc/html/rfc6386#section-12.2:
The exact algorithm is as follows:
[...]
b[r][c] = clamp255(L[r]+ A[c] - P);
For the test images I'm looking at, it doesn't seem to make a
dramatic difference, but omitting it in `B_TM_PRED` did make
a dramatic difference, so add it. (Also, the spec demands it.)
|
|
`predicted_y_above` is initialized to a row of 127s, so we can just
read from it even in the first macroblock row.
No behavior change.
|
