The Linux `getopt_long` manpage tells users to reset `optind` to 1 when
scanning the same argument vector or a new argument vector again. This
makes sense, since `optind` denotes the _next_ option to be processed.
The behavior of setting `optind` to 0 doesn't seem to be specified
anywhere, so let's also remove that comment from `unistd.h`.
This makes it more economical to add more options here, and makes it
possible to use similar API surface for the other image writers.
(It looks like nothing currently uses this optional parameter, but
having a way to pass options to image writers seems like something
we generally want.)
This has always been unused, and after #8440 BMPWriter::dump()
unconditionally writes to m_compression, meaning even if this
method was called, it would have no effect.
Percentage line-height values are relative to 1em (i.e the font-size
of the element). We have to resolve their computed values before
proceeding with inheritance.
If normal flow layout has caused us to progress past the current
innermost float in the block axis, we still need to consider the floats
stacked outside of it.
Fix this by always walking the currently stacked floats from innermost
to outermost when placing new floats.
This makes all the code for fill_path() member functions of the painter,
and moves them into a new FillPathImplementation.cpp. This allows us
to avoid polluting Painter.h with implementation details, and makes
the edit, compile, retry loop much shorter.
This improves fill_path() performance by adding an API to the painter
that allows painting an entire scanline rather than just a pixel.
With this paths can be clipped a scanline at a time rather than each
pixel, removing a fair amount of checks.
Along with optimized clipping, this can now use a fast_u32_fill() to
paint all but the subpixels of a scanline if a solid color with no
alpha channel is used (which is quite common in SVGs).
This reduces scrolling around on svg.html from 21% in set_pixel() and
19% in fill_path() to just 7.8% in fill_path (with set_pixel()
eliminated). Now fill_path() is far from the slowest code when
scrolling the page.
Use FlyString::from_deprecated_fly_string() in these instances instead
of FlyString::from_utf8(). As we convert to new FlyString/String we want
to be aware of these potential unnecessary allocations.
This doesn't return a completion in the spec as it doesn't need to
propagate any errors. It's also unused right now, which is probably why
no one noticed.
Until now we were just creating a stacking context for the tree root,
which usually is the viewport element. This lead to weird painting
behaviour when negative z-index children of the html element that
established their own stacking context were drawn below the canvas
background.
Now we establish a stacking context for both, the root element and the
viewport.
Removal of dummy execution context in
9aca54091a caused a crash in
`execute_async_script` because of empty execution contexts stack
during `create_resolving_functions` call.
When using the flex shrink factor, the flexible length resolution
algorithm was incorrectly ignoring the `frozen` flag on items and would
update the same items again, causing overconsumption of the remaining
free space on the flex line.
In case flex items had `margin: auto` on the primary flex axis, we were
still also distributing remaining space according to `justify-content`
rules. This lead to duplicated spacing in various places and overflows.
It looks like this issue was observed previously but missidentified
because there was logic to ignore margins at the start and end which
would partially paper over the root cause. However this created other
bugs (like for example not having a margin at beginning and end ;-)) and
I can find nothing in the spec or other browser behaviour that indicates
that this is something that should be done.
Now we skip justify-content space distribution alltogether if it has
already been distributed to auto margins.
By default, JPEGs use YCbCr to encode colors however other encoding
exist. This patch adds the logic to determine which transformation is
needed and support for RGB encoded JPEGs :^).
This half-standardized application specific segment is used for color
transform information. It means that the decoder is know informed if the
image uses YCbCr, RGB, CMYK or even YCCK.
This fixes a bug in the CSS Grid when there is a column and/or row gap,
as previously it would take the index of the incorrect column when
finding the `AvailableSize`.
There is a mild complication in the GridFormattingContext as the
OccupationGrid does not take into account the gap columns and rows that
later appear in the `Vector<TemporaryTrack>` columns and rows. The
PositionedBoxes are kind of a connection between the two, and so it's
now more explicit whether you would like to refer to a column by its
position taking into the gap columns/rows or not.
The draft CSS-FLEXBOX-1 spec had a more detailed description of this
algorithm, so let's use that as our basis for the implementation.
Test by Aliaksandr. :^)
When resolving these constraints to CSS pixel sizes, we have to resolve
padding-top and padding-bottom against the flex container's *width*,
not its height.
The padding-top and padding-bottom properties are relative to the
*width* of the containing block, not the height.
It's funny how we keep making this same mistake again and again. :^)
