The refactor of the border painting mainly to handle:
1. Single border with minor border radius.
2. Different border widths and border colors joined situations.
This refactor only apply to solid border.
The main differece is to use Path.fill to paint each border,
not fill_rect anymore. There's a special case need to consider.
The Path.fill will leave shared edge blank between two borders.
To handle this, we decide to combine the borders with same color
to paint together.
When specifying either `background-position-x: right` or
`background-position-y: bottom` without an offset value no
EdgeStyleValue was created.
However, the spec says the offset should be optional.
Now, if you do not provide an offset, it creates the EdgeStyleValue
with a default offset of 0 pixels.
Previously, it was assumed that only one filtering option, such as
`-u` or `-p` would be used at a time. With this PR, processes are now
shown if they match any of the specified filters.
Describe how to use the two new context and unified format options in
the diff utility. Also change the example comparison of two files so
they contain more lines as that is much more interesting (and useful).
This small utility is something we probably needed for a very long
time - a way to print memory statistics in an elegant manner.
This utility opens /sys/kernel/memstat, reads it and decode the values
into human readable entries, possibly even into human-readable sizes.
Use LibCore ArgsParser to parse the parameters instead of using the raw
strings from the argv (Main::Arguments) array.
Also, use indicative names for variables in the code so the utility code
is more understandable.
I could not find a vector graphic of Buggie, so I've now made one
and am adding it exclusively as a .tvg :^)
Should be easy to convert to an SVG too :)
This man page was referenced from some places. This is mostly a
condensed version of the POSIX behavior that the system call
implementation already has, only documenting the obviously visible
errors (in source code) we do actually report.
This is a preparation before we can create a usable mechanism to use
filesystem-specific mount flags.
To keep some compatibility with userland code, LibC and LibCore mount
functions are kept being usable, but now instead of doing an "atomic"
syscall, they do multiple syscalls to perform the complete procedure of
mounting a filesystem.
The FileBackedFileSystem IntrusiveList in the VFS code is now changed to
be protected by a Mutex, because when we mount a new filesystem, we need
to check if a filesystem is already created for a given source_fd so we
do a scan for that OpenFileDescription in that list. If we fail to find
an already-created filesystem we create a new one and register it in the
list if we successfully mounted it. We use a Mutex because we might need
to initiate disk access during the filesystem creation, which will take
other mutexes in other parts of the kernel, therefore making it not
possible to take a spinlock while doing this.
This change was a long time in the making ever since we obtained sample
rate awareness in the system. Now, each client has its own sample rate,
accessible via new IPC APIs, and the device sample rate is only
accessible via the management interface. AudioServer takes care of
resampling client streams into the device sample rate. Therefore, the
main improvement introduced with this commit is full responsiveness to
sample rate changes; all open audio programs will continue to play at
correct speed with the audio resampled to the new device rate.
The immediate benefits are manifold:
- Gets rid of the legacy hardware sample rate IPC message in the
non-managing client
- Removes duplicate resampling and sample index rescaling code
everywhere
- Avoids potential sample index scaling bugs in SoundPlayer (which have
happened many times before) and fixes a sample index scaling bug in
aplay
- Removes several FIXMEs
- Reduces amount of sample copying in all applications (especially
Piano, where this is critical), improving performance
- Reduces number of resampling users, making future API changes (which
will need to happen for correct resampling to be implemented) easier
I also threw in a simple race condition fix for Piano's audio player
loop.
Previously, the `-p` option printed the path of the file being
processed before any strings for that file. The `-f` prints the file
path before each string . This matches the behavior of strings on
Linux and FreeBSD.
This is a sensible separation of concerns that mirrors the WindowServer
IPC split. On the one hand, there is the "normal" audio interface, used
for clients that play audio, which is the primary service of
AudioServer. On the other hand, there is the management interface,
which, like the WindowManager endpoint, provides higher-level control
over clients and the server itself.
The reasoning for this split are manifold, as mentioned we are mirroring
the WindowServer split. Another indication to the sensibility of the
split is that no single audio client used the APIs of both interfaces.
Also, useless audio queues are no longer created for managing clients
(since those don't even exist, just like there's no window backing
bitmap for window managing clients), eliminating any bugs that may occur
there as they have in the past.
Implementation-wise, we just move all the APIs and implementations from
the old AudioServer into the AudioManagerServer (and respective clients,
of course). There is one point of duplication, namely the hardware
sample rate. This will be fixed in combination with per-client sample
rate, eliminating client-side resampling and the related update bugs.
For now, we keep one legacy API to simplify the transition.
The new AudioManagerServer also gains a hardware sample rate change
callback to have exact symmetry on the main server parameters (getter,
setter, and callback).
If more than one file is specified on the command line and the `-L`
option is used, the totals field will show the longest line
encountered; it is not a sum like the other values.
The intention for this utility is to eventually become a general-purpose
multimedia conversion tool like ffmpeg (except probably not with as many
supported formats, stream mappings and filters). For now, we can not
write any video format so the added complexity is not necessary at the
moment.
