...simply by using LittleEndianInputBitStream::read_bit() instead of
read_bits(1). This puts us on the fast path for single-bit reads.
There's still lots of money on the table for bigger optimizations to
claim here, just picking an embarrassingly low-hanging fruit. :^)
Instead of going byte by byte, copy entire blocks at once and only check
if we need to update the state once per block. This pretty much
eliminates `::update()` from profiles and measurably improves
performance for utilities like `sha256sum`.
We were not testing this logic and I caused a regression while
modifying some of the hashing code, so let's add these. Note that I only
added two tests to test both 'families' of implementations for the SHA
hashes.
This will allow these to be more easily reused for other inputs.
Note that we need this as the base LibGfx pallet does not quite have
the required range for HTML inputs (though these shades are based off
the LibGfx palette).
The `read_image_data` function of each one of[PBM, PGM, PPM]Loader use
the same structure to read an image. This patch harmonizes the three
functions and use finite loops instead of reading until EOF. It allows
to quit early on bloated file, but it's mainly done for refactoring
purpose.
The function signature goes from:
`bool read_number(Streamer& streamer, TValue* value)`
to
`ErrorOr<u16> read_number(Streamer& streamer)`
It allows us to, on one hand use `ErrorOr` for error propagation,
removing an out parameter in the meantime, and on the other hand remove
the useless template.
This commit also starts the adoption of ErrorOr<T> and the String class
in ImageViewer. However, there is still a few more changes that could
be made.
Since the actions of using LibFSAC and using String in more places are
tightly coupled, I decided to put them in one commit.
A 1px drop shadow from the track was peeking out behind the knob when
at rightmost or lowest position. That made it look like it was possible
to drag the knob even further right or down. Painting the track 1px
shorter seems like a good compromise to avoid the problem.
When clicking the value slider bar, the knob was not positioned as
close to the mouse as expected. When moving the mouse right, the knob
would lag a bit behind, and the cursor would eventually be outside the
knob.
The bug was due to knob_rect() taking knob_thickness into account to
prevent the knob from protruding outside the bar. The value_at(pos)
calculated the relative position based on the entire width of the bar.
This discrepancy is fixed by taking knob_thickness into account in
value_at(position).
When dragging value slider left, the handle would snap to lower value
with the slightest move of the mouse. When dragging to the right
however, it would take a lot more movement to cause a change in value.
This asymmetry made it feel awkward to drag the mouse around. It was
caused by always rounding down using a cast to int. By rounding to the
nearest integer first, we ensure symmetric behavior.
When dragging the slider handle left/down, the handle would
snap to lower value with the slightest move of the mouse. When dragging
to the right/up however, it would take a lot more movement to cause
a change in value. This asymmetry made it feel really awkward to drag
the slider. It was caused by always rounding down using a cast to int.
By rounding to the nearest integer first, we ensure symmetric behavior.
