Otherwise Qt would not find the wayland plugin it is instructed to use
via QT_QPA_PLATFORM, and would fall back to the second option, xcb,
which looks rather sad in a modern Wayland environment :^)
This feels like something that should be addressed upstream in nixpkgs
eventually.
This is necessary to support the wayland protocol.
I also moved the CMSG_* macros to the kernel API since they are used in
both kernel and userspace.
this does not break ntpquery/SCM_TIMESTAMP.
There was a bug in which bound Inodes would lose all their references
(because localsocket does not reference them), and they would be
deallocated, and clients would get ECONNREFUSED as a result. now
LocalSocket has a strong reference to inode so that the inode will live
as long as the socket, and Inode has a weak reference to the socket,
because if the socket stops being referenced anywhere it should not be
bound.
This still prevents the reference loop that
220b7dd779 was trying to fix.
With this, simple v4 matrix profiles using parametric curves, such as
Compact-ICC-Profiles/profiles/sRGB-v4.icc, can be completely serialized
and the serialized file can be read again by `icc` :^)
The patch also contains modifications on several classes, functions or
files that are related to the `JPGLoader`.
Renaming include:
- JPGLoader{.h, .cpp}
- JPGImageDecoderPlugin
- JPGLoadingContext
- JPG_DEBUG
- decode_jpg
- FuzzJPGLoader.cpp
- Few string literals or texts
To add grouping to a number, we take a string such as "123456.123" and
break it into integer and fraction parts. Then we take the integer part
and break it into locale-specific sized groups to inject the locale's
group separator (e.g. a comma in en-US). We currently create new strings
for each of these groups. Instead, we can use the shared superstring
method to avoid all of that string copying.
Even though we currently build all of Userland and the Kernel with the
-mstrict-align flag, the compiler will still emit unaligned memory
accesses. To work around this, we disable the check for now. See
https://github.com/SerenityOS/serenity/issues/17516 for the relevant
issue.
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 :^)
