This removes all usages of the non-standard put helper method and
replaces all of it's usages with the specification required alternative
or with define_direct_property where appropriate.
These are usually incorrect, and people sometimes forget to add the
correct values as a result of them being optional, so they should just
be specified explicitly.
This removes all usages of the non-standard define_property helper
method and replaces all it's usages with the specification required
alternative or with define_direct_property where appropriate.
Since the object rewrite native property getters/setters are always
called with the owning object as the this_value, which in this case is
an Array object, and as such this checks are always false.
The Number constructor previously didn't support converting BigInts to
regular numbers, so I used parseInt as a workaround.
Since it now supports this, this workaround is no longer needed.
It didn't really make sense for the transparency grid to extend
infinitely around the image. Now the grid is only visible underneath
the image, which matches how most other editors behave.
We now divide each scanline into prologue, aligned run, and epilogue.
Basically, we draw enough pixels one-by-one until we reach a grid
intersection. Then we draw full grid cell slices using fast memory
fills. Finally we go back to one-by-one for the epilogue.
This is roughly 2.5x faster in a microbenchmark and no longer dominates
the ImageViewer and PixelPaint resizing profiles.
The call to enumerable_own_property_names in the non-array case was
missing an exception check.
Fixes 1 test262 case (JSON/parse/reviver-object-own-keys-err.js)
This requires variables that should be exported to the script host
or to other scripts to be declared as var (such as in test-common.js),
since lexically-scoped variables won't be visible.
This was an old SerenityOS-specific syscall for donating the remainder
of the calling thread's time-slice to another thread within the same
process.
Now that Threading::Lock uses a pthread_mutex_t internally, we no
longer need this syscall, which allows us to get rid of a surprising
amount of unnecessary scheduler logic. :^)
This class was previously a spinlock that would call sys$donate()
to donate its timeslice to whichever thread was holding the lock.
Now that pthread_mutex_t has a fast path, let's implement Lock on top
of that instead and get rid of the last remaining user of sys$donate().
- Fix evaluation order: IsArray(O) should always be called and before
Get(O, @@toStringTag), previously it was the other way around and
IsArray would only be called if @@toStringTag is not a string
- Add missing exception checks to both function calls
- Add missing builtin tag for arguments object
Also, while we're here:
- Update variable names to match spec
- Add spec step comments
Previously move_selection() did not work as expected. Instead store the
selected layer index in a member variable and continue to cycle through
the layers when you come to the start/end. Also use it to scroll into
view. Lastly rename the function to cycle_through_selection() to make it
clearer what it does.
This enables the layer menu as a context menu in LayerListWidget,
setting the clicked layer as active for now, but in the future it
would be nice to have custom menu applying to the clicked layer instead
of the active layer.
This implementation does not use locking or condition variables
internally; it's purely based on atomics and futexes.
Notably, concurrent sem_wait() and sem_post() calls can run *completely
in parallel* without slowing each other down, as long as there are empty
slots for them all to succeed without blocking.
Additionally, sem_wait() never executes an atomic operation with release
ordering, and sem_post() never executes an atomic operation with acquire
ordering (unless you count the syscall). This means the compiler and the
hardware are free to reorder code *into* the critical section.
This implementation features a fast path for pthread_cond_signal() and
pthread_cond_broadcast() for the case there's no thread waiting, and
does not exhibit the "thundering herd" issue in
pthread_cond_broadcast().
Fixes https://github.com/SerenityOS/serenity/issues/8432
This is a private function that locks the lock much like the regular
pthread_mutex_lock(), but causes the corresponding unlock operation to
always assume there may be other waiters. This is useful in case some
waiters are made to wait on the mutex's futex directly, without going
through pthread_mutex_lock(). This is going to be used by the condition
variable implementation in the next commit.
pthread_mutex is now an actual "sleeping" mutex, and not just a
spinlock! It still has a fast path that only uses atomics and (in the
successful case) returns immediately without sleeping. In case of
contention, it calls futex_wait(), which lets the kernel scheduler put
this thread to sleep, *and* lets it know exactly when to consider
scheduling it again.
These are convinient wrappers over the most used futex operations.
futex_wait() also does some smarts for timeout and clock handling.
Use the new futex_wait() instead of a similar private helper in
LibPthread.
Piano is an old application that predates AudioServer. For this reason,
it was architected to directly talk to the soundcard via the /dev/audio
device. This caused multiple problems including simultaneous playback
issues, no ability to change volume/mute for Piano and more.
This change moves Piano to use AudioServer like any well-behaved audio
application :^) The track processing and IPC communication is moved to
the main thread because IPC doesn't like multi-threading. For this, the
new AudioPlayerLoop class is utilized that should evolve into the
DSP->AudioServer interface in the future.
Because Piano's CPU utilization has gotten so low (about 3-6%), the UI
update loop is switched back to render at exactly 60fps.
This is an important commit on the road to #6528.
async_enqueue() is a wrapper over the async_enqueue_buffer() call
to AudioServer. This allows users to asyncronously enqueue audio
samples, when the program requires non-blocking audio streaming.
This also makes ClientConnection use east-const everywhere.
We don't know what is a good time to wait after an audio buffer fails to
be processed by AudioServer. However, it seems like decreasing the wait
time to 10ms after such a failure should improve latency and has not
caused issues in my testing. After all, 10ms is quite some time in audio
sample magnitudes.
