This stuff has moved from a mixin defined by the DOM Parsing spec, over
to the HTML spec, where they are now defined as partial interfaces for
Element and ShadowRoot.
There's also some new functionality that we don't implement yet, so
patch marks them as FIXME properties.
And let the old shadow_root(), which was only supposed to be used by
bindings, be called shadow_root_for_bindings() instead.
This makes it much easier to read DOM code, and we don't have to worry
about when to use shadow_root_internal() or why.
The placeholder text shows "Search or enter web address" which doesn't
tell the user about *how* the search will be performed. Other popular
open source browsers show the search engine that will be used. For
example:
Chromium: "Search **engine** or type a URL"
Firefox: "Search with **engine** or enter address"
This change changes the placeholder text of the location bar to show
"Search with **engine** or enter web address".
Implement setLineDash() and getLineDash() in CanvasPathDrawingStyles,
which write/read from the CanvasState object.
This doesn't implement the actual drawing of a dashed line, but at least
sites using the Chart.js library no longer fail with an exception.
Unfortunately the Painter classes don't support dashed/dotted lines
based on segments yet.
Any data that sticks around in a decoder, especially frames that
haven't been retrieved, may cause issues for playback.
This is especially the case with H.264, since its arbitrary frame
ordering to allow reference frames to precede B-frames causes it to
hold onto frames, and causes the playback manager to get back a frame
at a completely wrong timestamp after seeking.
The timestamp offset of a block was being converted from i16 to u64, so
negative values would overflow and cause timestamps that fall before
the cluster's timestamp from being close to the minimum representable
i64.
The math is also now done using saturating operations to prevent any
other similar issues from occurring.
H.264 in Matroska can have blocks with unordered timestamps. Without
passing these as the presentation timestamp into the FFmpeg decoder,
the frames will not be returned in chronological order.
VideoFrame will now include a timestamp that is used by the
PlaybackManager, rather than assuming that it is the same timestamp
returned by the demuxer.
VP9 continues to function, but this also allows AV1 to be decoded. With
this commit, H.264 is still non-functional, as the decoder requires
some extra initial data from the track definition in the Matroska file.
These aren't particularly small objects, but we were still copying them
around all over the place. When TrackEntry contains data buffers, they
won't need to be copied as well.
This should halve the size of frames in memory for frames with 8-bit
color components, which is the majority of videos.
Calculation of the size of subsampled planes has also been consolidated
into a struct. There are likely some places that will still need to
change over to this, but it should prevent issues due to differing
handling of rounding/ceiling.
BT.2020 will mainly be used with bit depths greater than 8, so having
this specialization is mostly pointless until we use fixed-point math
for higher bit depths.
It is not needed by code generators anymore, so it is not needed in the
Lagom tools build. And it is not needed as an object library anymore; it
was created this way so it could be included in Serenity's LibC.
Prior to this change, our find in page function always highlighted the
first match whenever the query was updated. After this change the
current match index is set such that it is the first match to occur
after the end of the current selection.
This means the current match position is not lost if the user modifies
their existing query.
This matches the behavior of find in page in other browsers.
Using mmap-allocated memory for backing stores does not allow us to
benefit from using GPU-accelerated painting, because all the performance
increase we get is mostly negated by reading the GPU-allocated texture
back into RAM, so it can be shared with the browser process.
With IOSurface, we get a framebuffer that is both shareable between
processes and can be used as underlying memory for an OpenGL/Metal
texture.
This change does not yet benefit from using IOSurface and merely wraps
them into Gfx::Bitmap to be used by the CPU painter.
