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`.
Per-channel values of the pixel color are now displayed in the status
bar when the PickerTool is selected. This information obviously updates
on mousemove.
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 is done with 2 major steps:
1. Remove JailManagement singleton and use a structure that resembles
what we have with the Process object. This is required later for the
second step in this commit, but on its own, is a major change that
removes this clunky singleton that had no real usage by itself.
2. Use IntrusiveLists to keep references to Process objects in the same
Jail so it will be much more straightforward to iterate on this kind
of objects when needed. Previously we locked the entire Process list
and we did a simple pointer comparison to check if the checked
Process we iterate on is in the same Jail or not, which required
taking multiple Spinlocks in a very clumsy and heavyweight way.
At the moment, all it can do is read all image formats that LibGfx can
read and save to any image format that LibGfx can write (currently bmp,
png, qoi).
Currently, it drops all image metadata (including color profiles).
Over time, this could learn tricks like keeping color profiles,
converting an image to a different color profile, cropping out a part of
an image, and so on.
"image" was an alias for "qemu-image".
I want to add an `image` userland utility, which clashes with that
shortname.
So remove the existing "image" target. It was just an alias for
"qemu-image".
If you use serenity.sh to build, nothing changes. This only affects you
if you run ninja manually -- you now have to say `ninja qemu-image` to
build the disk image.
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.
Let's add FlyString::from_deprecated_fly_string() so we can use it
instead of FlyString::from_utf8(). This will make it easier to detect
potential unncessary allocations as we transfer to FlyString.
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.
The one behavior difference here is that the statusbar used to display
"Unknown" for unknown file types, and "Markdown" for md, but we now
display "Plain Text" for all file types without syntax highlighters.
Commit: 2c84466ad8 ("Kernel/Storage: Introduce new boot device
addressing modes") changed the way we pass the boot device parameter.
That commit missed updating boot parameter in the run.sh script for NVMe
boot devices.
The LUN.target_id parameter points to a NVMe Namespace which starts from
1 and not 0. Fix the document to reflect the same while addressing a
nvme device in the boot parameters
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.
The scope of these entries is not proportional to Brian's capacity for
code review at the moment, so let's stop marking him as "code owner" on
almost every PR. :^)
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.
