Before this change, we used Gfx::Bitmap to represent both decoded
images that are not going to be mutated and bitmaps corresponding
to canvases that could be mutated.
This change introduces a wrapper for bitmaps that are not going to be
mutated, so the painter could do caching: texture caching in the case
of GPU painter and potentially scaled bitmap caching in the case of CPU
painter.
Previously, we were returning an empty optional if key contained a
numerical value which was not stored as double. Stop doing that and
rename the method to signify the change in the behavior.
Apparently, this fixes bug in an InspectorWidget in Ladybird on
Serenity: it showed 0 for element's boxes with integer sizes.
When scrolling to the inspected element, if we scroll to its exact
position, it would often be placed behind the fixed header at the top of
the WebView. This patch gives the scroll a bit of an offset to scroll
comfortably beneath the header.
The `page_did_request_scroll_to` API takes a CSS position, and thus
callers should not scale to device pixels before invoking it. Instead,
align this API with (most) other PageHost APIs which scale to device
pixels before sending the corresponding IPC message.
In the AppKit chrome, convert the provided device pixel position to a
widget position.
The CardPainter in LibCards caches already painted bitmaps. This adds a
helper that gets the bitmap from a cache or creates a new one, if the it
doesn't exist yet. It does this by calling a creator function with the
new bitmap, which can then paint into the bitmap. This makes the code a
bit simpler and shorter.
In Spider, cards that can't be moved are now shown as disabled using the
helpers in LibCards. This makes it much easier to see what can be moved
and to where, overall improving the game significantly!
This adds a little helper in Cards::CardStack that updates the disabled
flags for its cards depending on a movement rule. It does this by
searching from the bottom up for the last card that is valid. It then
sets the disabled flag for all cards above that card, if it isn't upside
down.
These wrappers will make it much easier to do various operations on the
different ArrayBuffer-related classes in LibWeb compared to the current
solution, which is to just accept a Handle<Object> everywhere (and use
"any" in the *.idl files).
Co-Authored-By: Matthew Olsson <mattco@serenityos.org>
The one deviation from the spec here is to use this in the WOFF
TableDirectoryEntry's tag field. However, *not* making that a Tag made
a lot of things more complicated than they need to be.
A few small changes that didn't seem to deserve separate commits:
- Mark it as packed to remove compiler complaints when it's a member of
a packed struct.
- Add a default constructor for places where we fill in a struct
gradually.
- Restrict the constructor to exactly 4-character string literals.
- Add a to_u32() method for the one place that needs that.
While creating a new VM feels warm and fuzzy from an isolation
perspective, having multiple JS heaps in the same process is a footgun
waiting to happen. Additionally, there are still many places in LibWeb
that reach for the main thread VM to check for the current realm to do
things, such as Web::HTML::incumbent_settings_object().
For each stacking context with an opacity less than 1, we create a
separate framebuffer. We then blit the texture attached to this
framebuffer with the specified opacity.
To avoid the performance overhead of reading pixels from the texture
into Gfx::Bitmap, a new method that allows for direct blitting from
the texture is introduced, named blit_scaled_texture().
This was used to provided base functionality for model-based chromes for
viewing the DOM and accessibility trees. All chromes now use the WebView
inspector model for those trees, thus this class is unused.
This is modeled after a similar implementation for the JS console.
This client takes over an inspector WebView (created by the chrome) to
create the inspector application. Currently, this application includes
the DOM tree and accessibility tree as a first pass. It can later be
extended to included the style tables, the JS console itself, etc.
This is an internal object that must be explicitly enabled by the chrome
before it is added to the Window. The Inspector object will be used by a
special WebView that will replace all chrome-specific inspector windows.
The IDL defines methods that this WebView will need to inform the chrome
of various events, such as the user clicking a DOM node.
Setting the marker's content width here is causing the text that follows
the marker to be indented a bit too much. This is noticeable when a line
with a disclosure marker is followed by a line with any other marker. It
previously would look something like:
> Text inline with disclosure-closed marker
* Text inline with circle marker
# Text inline with square marker
Now the disclosure marker line matches other marker types:
> Text inline with disclosure-closed marker
* Text inline with circle marker
# Text inline with square marker
We were calling write syscall twice for every sample, which effectively
hurt the writer's performance.
With this change exporting a melody in the Piano app now takes less than
a second, which previously took about 20 seconds on my machine.
Additionally, I've removed an unused `WavWriter::file()` getter.
This will make window.open a lot easier to implement. As written, the
implementation of Navigable::choose_a_navigable now looks a lot closer
to the old BrowsingContext::choose_a_browsing_context. With the notable
exception that we still crash in many cases, and don't properly handle
multiple top-level traversables in the same WebContent process.
Ideally we would not create a layout node at all for these elements so
that every layout node would always have a paintable associated with it.
But for now, to fix the crash, just leave a FIXME and special case this
element.
Also leave a VERIFY to make it easier to debug this type of crash in the
future.
Fixes a crash seen on codecov.io for my 'patch' project.
SMasks are greyscale images that get used as alpha channel for a
different image.
JPEGs in PDFs are stored as streams with /DCTDecode filters, and
we have a separate code path for loading those in the PDF renderer.
That code path just calls our JPEG decoder, which creates bitmaps
with format BGRx8888.
So when we process an SMask for such a bitmap, we have to change
the bitmap's format to BGRA8888 in addition to setting alpha values
on all pixels.
It's perfectly possible for JavaScript to call unobserve() on an element
that hasn't been observed. Let's stop asserting if that happens. :^)
Fixes#22020
