This just calls Layout::try_add_spacer(), but saves you having to access
the Widget's Layout directly.
We verify that the Widget has a Layout, since it would be a programming
error if we tried to do so without one.
I can see small speedup of about 6-7% with this for some gradient
painting, though Tim has been able to see an ~30% speedup in some
resizing cases so this seems like a worthwhile change.
Co-authored-by: Tim Ledbetter <timledbetter@gmail.com>
Currently, if you use the left/right arrow keys to move over a multi-
code point glyph, we will move through that glyph one code point at a
time. This means you can "pause" your movement in the middle of a glyph
and delete a subsection of a grapheme cluster. This now moves the cursor
across the entire cluster.
Visually, we will need to separately track physical and virtual cursor
positions. That is, when you move across a multi-code point glyph, the
visual cursor should only move one position at a time, while a physical
cursor stores the "real" position in terms of number of code points.
This also converts a couple of ints to auto - these are actually size_t,
and are being passed to functions that expect size_t, so let's not cast
them to ints.
Instead of rehashing on collisions, we use Robin Hood hashing: a simple
linear probe where we keep track of the distance between the bucket and
its ideal position. On insertion, we allow a new bucket to "steal" the
position of "rich" buckets (those near their ideal position) and move
them further down.
On removal, we shift buckets back up into the freed slot, decrementing
their distance while doing so.
This behavior automatically optimizes the number of required probes for
any value, and removes the need for periodic rehashing (except when
expanding the capacity).
The iterator used to find an intrinsic accessor is used after calling
`HashMap.remove()` on it, which works for our current implementation but
will fall apart when you consider that modifications to the hash map
might invalidate all existing iterators that came from it, as many
implementations do.
Since we're aiming to replace our `HashTable` implementation with
something new, let's fix this first :^)
This adds three flags to icc:
* --reencode-to=<file> re-serializes a profile to a given file,
using Gfx::ICC::encode(). This is mainly useful for testing that
code.
* --dump-to=<file> dumps the raw ICC profile bytes read from the
input to disk. This is useful for extracting ICC profiles from
images, and for comparing the raw profile bytes to the profile
bytes written by --reencode-to=.
If either of these flags is passed, icc by default no longer dumps
the icc data to stdout. To force priting of the data even if either
of these flags is present, this also adds:
* --print, which forces printing ICC contents, even if either or
both of the icc-data writing flags are present.
For now, this can write the profile header.
`icc` refuses to dump its contents since the required copyrightTag,
profileDescriptionTag, and required per-device-class tags are missing,
but it looks ok in a hex editor.
header_size is already set to 0 if context.is_included_in_ico is true
and to bmp_header_size else, so we can remove some redundant checks
for context.is_included_in_ico.
No behavior change.
This approximation tries to generate values within 0.1% of their actual
expected value. Microbenchmarks indicate that this iterative SIMD
version can be up to 60x faster than `AK::SIMD::exp`.
This makes use of the new [UseNewAKString] extended attribute. Using
Vector storage will make it easier to make this interface into an IDL
iterable. It seems the reason it didn't use Vector originally was due
to awkward DeprecatedString -> String conversions.
Adding the [UseNewAKString] extended attribute to an interface will
cause all IDL string types to use String instead of DeprecatedString.
This is done on an per interface level instead of per type/parameter
because:
- It's much simpler to implement, as the generators can already access
the interface's extended attributes. Doing it per type/parameter
would mean parsing and piping extended attributes for each type that
doesn't already take extended attributes, such as unions.
- Allows more incremental adoption of AK::String. For example, adding
[UseNewAKString] to BodyInit would require refactoring Request,
Response and XMLHttpRequest to AK::String in one swoop. Doing it on
the interface allows you to convert just XHR and its dependencies at
once, for example.
- Simple string return types (i.e. not parameterised or not in a union)
already accept any of the string types JS::PrimitiveString::create
accepts. For example, you can add [UseNewAKString] to DOMStringMap to
convert Element attributes to AK::String and still return AK::String
from get_attribute, without adding [UseNewAKString] to Element.
- Adding [UseNewAKString] to one function typically means adding it to
a bunch of other functions, if not the rest of them. For example,
adding [UseNewAKString] to the parameters FormData.append would
either mean converting AK::String to AK::DeprecatedString or storing
the AK::String as-is, making the other functions of FormData have to
convert back from AK::String or also support AK::String.
