With this change, chrome no longer has to ask the WebContent process
to paint the next frame into a specified bitmap. Instead, it allocates
bitmaps and sends them to WebContent, which then lets chrome know when
the painting is done.
This work is a preparation to move the execution of painting commands
into a separate thread. Now, it is much easier to start working on the
next frame while the current one is still rendering. This is because
WebContent does not have to inform chrome that the current frame is
ready before it can request the next frame.
Additionally, as a side bonus, we can now eliminate the
did_invalidate_content_rect and did_change_selection IPC calls. These
were used solely for the purpose of informing chrome that it needed to
request a repaint.
While it would be more hygienic to get a fresh Navigable each time,
loading `about:blank` still means we discard the current Document.
This does noticeably increase the duration of running the LibWeb test
suite. On my machine, we go from ~5.5 seconds to ~7.7.
This caused a dangling reference down the line, which lead to funny
things like the following:
> cd Bui[tab]
> cd Bui^@^@
By returning a direct reference to the suggestion in question, we can be
sure that the referenced object is alive until the next suggestion
cycle.
UnassociatedAlpha is the one used by GIMP when generating TIFF images
with transparency. Support is added for Grayscale and RGB images as it's
the two that we support right now but managing transparency should be
really straightforward for other types as well.
Before this change, it was possible for a text test to finish before
on_load_finish() was triggered, resulting in the subsequent test
receiving the load event from the previous test.
The idea is to massage the inline image data into something that
looks like a regular image, and then use the normal image drawing code:
We translate the inline image abbreviations to the expanded version at
rendering time, then unfilter (i.e. uncompress) the image data at
rendering time, and the go down the usual image drawing path.
Normal streams are unfiltered when they're first accessed, but
inline image streams live in a page's drawing operators, and this
fits the current approach of parsing a page's operators anew
every time the page is rendered.
(We also need to add some special-case handling for color spaces
of inline images: Inline images can use named color spaces, while
regular images always use direct color space objects.)
This is to allow future changes to do cross-process MessagePorts in an
implementation-agnostic way. Add some tests for this behavior.
Delivering messages that were posted to a MessagePort just before it was
transferred is not yet implemented still.
This change fixes a bug with running tests where, if one of the
previous tests changes the scroll position, all subsequent tests that
rely on the scroll position will fail. This is because the headless
browser never resets the viewport offset.
Currently, if we run CommandPalette, it's blank by default and it's not
displaying all available commands for the app in which it has been
opened. User has to enter something and then delete it to see
all commands. This patch makes all available commands being displayed
by default on start of CommandPalette, by allowing incoming empty
string to be invalidated in FilteringProxyModel, instead of returning
instantly.
As per the specification, TIFF readers should gracefully skip samples
that they are not able to interpret.
This patch allow us to read `strike.tif` from the libtiff test suite as
an RGB image.
The number of samples is not a good measure to deduce the type of image
we are decoding. As per the TIFF spec, the PhotometricInterpretation tag
is required and we should use that instead.
We create a inline_image_end operator that has all the relevant data
in a synthetic StreamObject.
inline_image_end is still a RENDERER_TODO(), so no real behavior
change. (Previously we'd call only inline_image_begin, so string the
todo message is about is now a bit different. But no interesting
behavior change.)
This patch adds basic support for the SVG `<textPath>`, so it supports
placing text along a path, but none of the extra attributes for
controlling the layout of the text. This is enough to correctly display
the MDN example.
This changes the splitting to use a stack, which ensures the resulting
line segments follow the path in order. This will be important for SVG
`<textPath>`s which place text along a path.
Use a LocalSocket to represent the connection between two message ports.
The concept of the port message queue is still missing, however. When
that concept is implemented, the "steps" in step 7 of the message port
transfer steps will need to send the serialized data over the connected
socketpair and run in the event loop of the process that holds onto the
other side of the message port. Doing this should allow centralizing the
behavior of postMessage for Window, MessagePorts and Workers.
When calling `running_execution_context` from other VM APIs, and the
execution context stack is empty, the verification message is inlined
from AK::Vector. Add a specific VERIFY to `running_execution_context` to
help diagnose this issue better.
This compression (tag Compression=2) is not very popular on its own, but
a base to implement CCITT3 2D and CCITT4 compressions.
As the format has no real benefits, it is quite hard to find an app that
accepts tho encode that for you. So I used the following program that
calls `libtiff` directly:
```cpp
#include <vector>
#include <cstdlib>
#include <iostream>
#include <tiffio.h>
// An array containing 0 and 1 of length width * height.
extern std::vector<uint8_t> array;
int main() {
// From: https://stackoverflow.com/a/34257789
TIFF *image = TIFFOpen("input.tif", "w");
int const width = 400;
int const height = 300;
TIFFSetField(image, TIFFTAG_IMAGEWIDTH, width);
TIFFSetField(image, TIFFTAG_IMAGELENGTH, height);
TIFFSetField(image, TIFFTAG_PHOTOMETRIC, 0);
TIFFSetField(image, TIFFTAG_COMPRESSION, COMPRESSION_CCITTRLE);
TIFFSetField(image, TIFFTAG_BITSPERSAMPLE, 1);
TIFFSetField(image, TIFFTAG_SAMPLESPERPIXEL, 1);
TIFFSetField(image, TIFFTAG_ROWSPERSTRIP, 1);
std::vector<uint8_t> scan_line(width / 8 + 8, 0);
int count = 0;
for (int i = 0; i < height; i++) {
std::fill(scan_line.begin(), scan_line.end(), 0);
for (int x = 0; x < width; ++x) {
uint8_t eight_pixels = scan_line.at(x / 8);
eight_pixels = eight_pixels << 1;
eight_pixels |= !array.at(i * width + x);
scan_line.at(x / 8) = eight_pixels;
}
int bytes = int(width / 8.0 + 0.5);
if (TIFFWriteScanline(image, scan_line.data(), i, bytes) != 1)
std::cerr << "Something went wrong\n";
}
TIFFClose(image);
}
```
As pointed out by @nico, while doing a right-shift to downscale is fine,
a left-shift to upscale gives wrong results. As an example, imagine a 2-
bits value containing 3, left-shifting it would give 192 instead of 255.
