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.
Allows WebContentClient to get pid of WebContent process right after
creation, so there is no window between forking and
notify_process_information() IPC response, when client doesn't know the
pid.
In upcoming changes, bitmap is going to be used to wrap the memory of
the IOSurface, and we will want to release the corresponding IOSurface
along with the bitmap.
In the upcoming changes, we are going to switch macOS to using an
IOSurface for the backing store. This change will simplify the process
of sharing an IOSurface between processes because we already have the
MachPortServer running in the browser, and WebContent knows how to
locate the corresponding server.
This change ensures that if a screenshot is requested between teardown
of paintable tree and relayout, we will wait for layout to complete
before taking a screenshot.
LibLocale was split off from LibUnicode a couple years ago to reduce the
number of applications on SerenityOS that depend on CLDR data. Now that
we use ICU, both LibUnicode and LibLocale are actually linking in this
data. And since vcpkg gives us static libraries, both libraries are over
30MB in size.
This patch reverts the separation and merges LibLocale into LibUnicode
again. We now have just one library that includes the ICU data.
Further, this will let LibUnicode share the locale cache that previously
would only exist in LibLocale.
We only need LibCoreMinimal for the lagom-tools build. In particular, by
removing LibUnicode, we remove the lagom-tools dependence on the system
ICU package, as we do not have vcpkg hooked into this build. (We could
probably add vcpkg here, but since this libraries aren't even needed, we
don't need to bother).
When any LibCore file (or any of its dependents) changes, we have to
regenerate all IDL bindings. By depending on LibCoreMinimal, the number
of impacting files greatly reduces.
As an example, changing a .cpp file in LibUnicode would previously cause
about 1800 ninja targets to rebuild. This is now reduced to about 200.
If a flex item has a preferred aspect ratio and the flex basis is not
definite, we were falling back to using stretch-fit for the main size,
since that appeared to match other browsers.
However, we missed the case where we actually have a definite cross size
through which the preferred aspect ratio can be naturally resolved.
Most users will be building with Xcode Clang on macOS anyway, as our
build scripts default to the system compiler if it's new enough. We
already have an upstream Clang-based workflow on Linux, so we won't lose
any compiler coverage by switching to Apple Clang on macOS.
This should help us avoid build breakages like #186.
