This reimplements image tiling instead of using `Painter::blit_tiled()`,
so that we will be able to handle CSS's more complicated repetition
rules. (Like `background-repeat: space`) Otherwise this does the same as
before. :^)
These aren't needed now that we render using background_layers instead.
The one casualty is the resolved style for background-repeat, but that
was incorrect anyway.
Instead of storing these as individual `background-foo` properties, we
combine them together into layers, since that is how they will be
painted. It also makes it more convenient to pass them around.
Previously, a `background-repeat` value of `no-repeat` in a direction
would cause the image to be drawn at exactly that size. This was fine if
the image was smaller than the element, but if it was larger, it would
draw outside its bounds. Now, it behaves itself. :^)
This now outputs valid CSS representing the background, instead of
confusing debug info.
We can't guarantee that all the longhands have the same number of
values, since while that's always the case when parsing, we also create
BackgroundStyleValues when producing the resolved style, which just
combines the longhands together.
Like the `background-foo` longhand properties (except
`background-color`), `background` allows multiple layers to be defined,
separated by commas. A layer does not necessarily contain something to
actually draw!
This parses as a `BackgroundStyleValue`, holding a `StyleValueList` for
each property. This is mostly to make expansion into longhands simpler -
if we had a list of `BackgroundStyleValue`s instead, one per layer, then
we would have to break it up per-property anyway when computing styles.
We now can parse lists of values for these properties:
- `background-attachment`
- `background-clip`
- `background-image`
- `background-origin`
- `background-position`
- `background-repeat`
- `background-size`
This uses two new Parser methods:
`parse_simple_comma_separated_value_list()` for the simple case when
each value is parsed from a single token; and
`parse_comma_separated_value_list()` which takes a lambda for when
parsing each value is more involved.
This also means that any unconsumed tokens at the end will make the
parsing fail as it should, where previously we just ignored them.
To make sure we don't lose changes, shared file mappings will now be
fully synced when they are unmapped, whether explicitly or implicitly
(by the program exiting/crashing/etc.)
This can incur a lot of work, since we don't keep track of dirty pages,
but that's something we can optimize down the road. :^)
This allows userspace to trigger a full (FIXME) flush of a shared file
mapping to disk. We iterate over all the mapped pages in the VMObject
and write them out to the underlying inode, one by one. This is rather
naive, and there's lots of room for improvement.
Note that shared file mappings are currently not possible since mmap()
returns ENOTSUP for PROT_WRITE+MAP_SHARED. That restriction will be
removed in a subsequent commit. :^)
This is a handy helper that copies out the full contents of a physical
page into a caller-provided buffer. It uses quickmapping internally
(and takes the MM lock for the duration.)
When the bytecode interpreter was converted to ThrowCompletionOr<Value>
it then also cleared the vm.exception() making it seem like no exception
was thrown.
Also removed the TRY_OR_DISCARD as that would skip the error handling
parts.
Turns out the only difference between our existing implementation and
the ECMA-402 implementation is we weren't passing the locales and
options list to each element.toLocaleString invocation.
This also adds spec comments to the definition.
This isn't a complete conversion to ErrorOr<void>, but a good chunk.
The end goal here is to propagate buffer allocation failures to the
caller, and allow the use of TRY() with formatting functions.
Also add slightly richer parse errors now that we can include a string
literal with returned errors.
This will allow us to use TRY() when working with JSON data.
We have no way of writing changes to memory-mapped files back to disk,
and software relying on this functionality for output would fail
miserably. Let's just return ENOTSUP instead to allow callers to fall
back to standard file IO instead of silently discarding writes.
This makes the LLD port work, which uses memory-mapped files to write
its output by default.
As noted at the top of this method, this is a naive implementation of
the Unicode plurality specification. But for now, we should tweak the
defintion of "many" to be "more than 2" (which is what I had in mind
when I wrote this, but forgot about fractions).
This wasn't the case for compact patterns, but unit patterns can contain
multiple (up to 2, really) identifiers that must each be recognized by
LibJS.
Each generated NumberFormat object now stores an array of identifiers
parsed. The format pattern itself is encoded with the index into this
array for that identifier, e.g. the compact format string "0K" will
become "{number}{compactIdentifier:0}".
This field is currently used to store the StringView into the compact
name/symbol in the format string. Units will need to store a similar
field, so rename the field to be more generic, and extract the parser
for it.
Instead of currency pattern lookups within select_currency_unit_pattern,
rename the method to select_pattern_with_plurality and accept any list
of patterns. This method will be needed for units.
Maintenance to stabilize the font.
- Added glyph FFFD
- Adjusted multiple glyphs for improved consistency
- Added a few glyphs to current ranges
- Added range Mende Kikakui 1E800-1E8DF (incomplete, I continued my work
in Katica)
Currently, we get the following results
-1 - -2 = -1
-2 - -1 = 1
Correct would be:
-1 - -2 = 1
-2 - -1 = -1
This was already attempted to be fixed in 7ed8970, but that change was
incorrect. This directly translates to LibJS BigInts having the same
incorrect behavior - it even was tested.
... and bring it back to try_load_from_file().
Prior to this change, changing the scaling option to x2 in the Display
Settings resulted in the following crash:
WindowServer(15:15): ASSERTION FAILED: bitmap->width() % scale_factor
== 0 ./Userland/Libraries/LibGfx/Bitmap.cpp:126
That was caused by two minor overlooked yaks:
- First, Bitmap::try_load_from_fd_and_close() tried to respect your
scale factor.
While requesting a bitmap from file can make a switcheroo to give you
a higher resolution bitmap, doing the same when you already have an fd
might violate the unveil agreement.
... but, it didn't do that.
It read bitmaps from requested fds, but also pretended all system
bitmaps in /res/ are the HiDPI ones when you enabled that mode.
- d85d741c59 used this function to deduplicate try_load_from_file().
It actually made this bug a lot easier to replicate!
Closes#10920
