Stowage/ladybird
2
0
Fork 0
mirror of https://github.com/LadybirdBrowser/ladybird.git synced 2025-10-19 15:43:20 +00:00
Code Issues Projects Releases Packages Wiki Activity
ladybird/Libraries/LibWeb/Painting/DisplayListRecorder.h

165 lines
6.5 KiB
C
Raw Normal View History

LibWeb: Introduce RecordingPainter to serialize painting commands This modification introduces a new layer to the painting process. The stacking context traversal no longer immediately calls the Gfx::Painter methods. Instead, it writes serialized painting commands into newly introduced RecordingPainter. Created list of commands is executed later to produce resulting bitmap. Producing painting command list will make it easier to add new optimizations: - It's simpler to check if the painting result is not visible in the viewport at the command level rather than during stacking context traversal. - Run painting in a separate thread. The painting thread can process serialized painting commands, while the main thread can work on the next paintable tree and safely invalidate the previous one. - As we consider GPU-accelerated painting support, it would be easier to back each painting command rather than constructing an alternative for the entire Gfx::Painter API.
2023-10-15 04:27:48 +02:00
/*
LibWeb: Verify that save/restore are balanced within paintable Unbalanced save/restore within display list items recorded for a paintable means that some state only relevant for the paintable leaks to subsequent paintables, which is never expected behavior.
2025-07-06 18:07:43 +02:00
* Copyright (c) 2023-2025, Aliaksandr Kalenik <kalenik.aliaksandr@gmail.com>
LibWeb: Introduce RecordingPainter to serialize painting commands This modification introduces a new layer to the painting process. The stacking context traversal no longer immediately calls the Gfx::Painter methods. Instead, it writes serialized painting commands into newly introduced RecordingPainter. Created list of commands is executed later to produce resulting bitmap. Producing painting command list will make it easier to add new optimizations: - It's simpler to check if the painting result is not visible in the viewport at the command level rather than during stacking context traversal. - Run painting in a separate thread. The painting thread can process serialized painting commands, while the main thread can work on the next paintable tree and safely invalidate the previous one. - As we consider GPU-accelerated painting support, it would be easier to back each painting command rather than constructing an alternative for the entire Gfx::Painter API.
2023-10-15 04:27:48 +02:00
*
* SPDX-License-Identifier: BSD-2-Clause
*/
#pragma once
#include <AK/Forward.h>
#include <AK/Vector.h>
#include <LibGfx/Color.h>
#include <LibGfx/Forward.h>
LibGfx+LibWeb: Add ImmutableBitmap for images bitmap caching in painter 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.
2023-11-24 14:45:45 +01:00
#include <LibGfx/ImmutableBitmap.h>
LibWeb: Rearrange code such that a lot less files include `Command.h` With this change number of recompiled files after modification of `Command.h` goes down from >1000 to <100.
2025-07-10 19:24:30 +02:00
#include <LibGfx/LineStyle.h>
LibWeb: Introduce RecordingPainter to serialize painting commands This modification introduces a new layer to the painting process. The stacking context traversal no longer immediately calls the Gfx::Painter methods. Instead, it writes serialized painting commands into newly introduced RecordingPainter. Created list of commands is executed later to produce resulting bitmap. Producing painting command list will make it easier to add new optimizations: - It's simpler to check if the painting result is not visible in the viewport at the command level rather than during stacking context traversal. - Run painting in a separate thread. The painting thread can process serialized painting commands, while the main thread can work on the next paintable tree and safely invalidate the previous one. - As we consider GPU-accelerated painting support, it would be easier to back each painting command rather than constructing an alternative for the entire Gfx::Painter API.
2023-10-15 04:27:48 +02:00
#include <LibGfx/PaintStyle.h>
#include <LibGfx/Palette.h>
LibWeb: Port painting to use the new Skia-backed Gfx::Path SVG and and CSS border rendering now sits on top of SkPath instead of the old Gfx::DeprecatedPath. Due to an imperceptible (255, 255, 255) vs (255, 254, 255) color diff in one ref test, I changed that test to not depend on border rendering for a positive result, since that was incidental.
2024-08-09 14:00:10 +02:00
#include <LibGfx/Path.h>
LibWeb: Introduce RecordingPainter to serialize painting commands This modification introduces a new layer to the painting process. The stacking context traversal no longer immediately calls the Gfx::Painter methods. Instead, it writes serialized painting commands into newly introduced RecordingPainter. Created list of commands is executed later to produce resulting bitmap. Producing painting command list will make it easier to add new optimizations: - It's simpler to check if the painting result is not visible in the viewport at the command level rather than during stacking context traversal. - Run painting in a separate thread. The painting thread can process serialized painting commands, while the main thread can work on the next paintable tree and safely invalidate the previous one. - As we consider GPU-accelerated painting support, it would be easier to back each painting command rather than constructing an alternative for the entire Gfx::Painter API.
2023-10-15 04:27:48 +02:00
#include <LibGfx/Point.h>
#include <LibGfx/Rect.h>
LibGfx: Move Gfx::Painter::ScalingMode => Gfx::ScalingMode This will allow users to avoid including Painter.h
2024-06-05 10:10:38 +02:00
#include <LibGfx/ScalingMode.h>
LibWeb: Rearrange code such that a lot less files include `Command.h` With this change number of recompiled files after modification of `Command.h` goes down from >1000 to <100.
2025-07-10 19:24:30 +02:00
#include <LibWeb/Forward.h>
LibWeb: Introduce RecordingPainter to serialize painting commands This modification introduces a new layer to the painting process. The stacking context traversal no longer immediately calls the Gfx::Painter methods. Instead, it writes serialized painting commands into newly introduced RecordingPainter. Created list of commands is executed later to produce resulting bitmap. Producing painting command list will make it easier to add new optimizations: - It's simpler to check if the painting result is not visible in the viewport at the command level rather than during stacking context traversal. - Run painting in a separate thread. The painting thread can process serialized painting commands, while the main thread can work on the next paintable tree and safely invalidate the previous one. - As we consider GPU-accelerated painting support, it would be easier to back each painting command rather than constructing an alternative for the entire Gfx::Painter API.
2023-10-15 04:27:48 +02:00
#include <LibWeb/Painting/BorderRadiiData.h>
#include <LibWeb/Painting/BorderRadiusCornerClipper.h>
LibWeb: Expand ClipFrame into clip rectangles during display list replay Until now, every paint phase of every PaintableBox injected its own clipping sequence into the display list: ``` before_paint: Save AddClipRect (1) ...clip rectangles for each containing block with clip... AddClipRect (N) paint: ...paint phase items... after_paint: Restore ``` Because we ran that sequence for every phase of every box, Skia had to rebuild clip stack `paint_phases * paintable_boxes` times. Worse, usually most paint phases contribute no visible drawing at all, yet we still had to emit clipping items because `before_paint()` has no way to know that in advance. This change takes a different approach: - Clip information is now attached as metadata `ClipFrame` to each DisplayList item. - `DisplayListPlayer` groups consecutive commands that share a `ClipFrame`, applying the clip once at the start of the group and restoring it once at the end. Going from 10 ms to 5 ms in rasterization on Discord might not sound like much, but keep in mind that for 60fps we have 16 ms per frame and there is a lot more work besides display list rasterization we do in each frame. * https://discord.com/channels/1247070541085671459/1247090064480014443 - DisplayList items: 81844 -> 3671 - rasterize time: 10 ms -> 5 ms - record time: 5 ms -> 3 ms * https://github.com/LadybirdBrowser/ladybird - DisplayList items: 7902 -> 1176 - rasterize time: 4 ms -> 4 ms - record time: 3 ms -> 2 ms
2025-07-13 03:55:24 +02:00
#include <LibWeb/Painting/ClipFrame.h>
LibWeb: Introduce RecordingPainter to serialize painting commands This modification introduces a new layer to the painting process. The stacking context traversal no longer immediately calls the Gfx::Painter methods. Instead, it writes serialized painting commands into newly introduced RecordingPainter. Created list of commands is executed later to produce resulting bitmap. Producing painting command list will make it easier to add new optimizations: - It's simpler to check if the painting result is not visible in the viewport at the command level rather than during stacking context traversal. - Run painting in a separate thread. The painting thread can process serialized painting commands, while the main thread can work on the next paintable tree and safely invalidate the previous one. - As we consider GPU-accelerated painting support, it would be easier to back each painting command rather than constructing an alternative for the entire Gfx::Painter API.
2023-10-15 04:27:48 +02:00
#include <LibWeb/Painting/GradientData.h>
LibWeb: Rename PaintOuterBoxShadowParams to PaintBoxShadowParams Drop "outer" from the name because this struct is used for both inner and outer shadows.
2024-06-07 18:06:25 +03:00
#include <LibWeb/Painting/PaintBoxShadowParams.h>
LibWeb: Merge FillPathUsingPaintStyle and FillPathUsingColor Use `Variant<PaintStyle, Gfx::Color>` in new `FillPath` instead of duplicating two almost identical display list items.
2025-08-02 21:16:51 +02:00
#include <LibWeb/Painting/PaintStyle.h>
LibWeb: Use `shape-rendering` to control anti aliasing for SVG paths Anti-aliasing is disabled if `shape-rendering` is set to `optimizeSpeed` or `crispEdges`.
2025-08-18 16:21:09 +01:00
#include <LibWeb/Painting/ShouldAntiAlias.h>
LibWeb: Introduce RecordingPainter to serialize painting commands This modification introduces a new layer to the painting process. The stacking context traversal no longer immediately calls the Gfx::Painter methods. Instead, it writes serialized painting commands into newly introduced RecordingPainter. Created list of commands is executed later to produce resulting bitmap. Producing painting command list will make it easier to add new optimizations: - It's simpler to check if the painting result is not visible in the viewport at the command level rather than during stacking context traversal. - Run painting in a separate thread. The painting thread can process serialized painting commands, while the main thread can work on the next paintable tree and safely invalidate the previous one. - As we consider GPU-accelerated painting support, it would be easier to back each painting command rather than constructing an alternative for the entire Gfx::Painter API.
2023-10-15 04:27:48 +02:00
namespace Web::Painting {
LibWeb: Rearrange code such that a lot less files include `Command.h` With this change number of recompiled files after modification of `Command.h` goes down from >1000 to <100.
2025-07-10 19:24:30 +02:00
struct StackingContextTransform {
Gfx::FloatPoint origin;
Gfx::FloatMatrix4x4 matrix;
};
LibWeb: Rename RecordingPainter to DisplayListRecorder Use more widely recognized name among browser engine developers.
2024-06-23 18:40:10 +02:00
class DisplayListRecorder {
AK_MAKE_NONCOPYABLE(DisplayListRecorder);
AK_MAKE_NONMOVABLE(DisplayListRecorder);
LibWeb+WebContent: Separate painting command list from RecordingPainter Separating the recorder list from the painter will allow us to save it for later execution without carrying along the painter's state. This will be useful once we have a separate thread for executing painting commands, to which we will have to transfer commands from the main thread. Preparation for https://github.com/SerenityOS/serenity/pull/23108
2024-02-14 16:36:42 +01:00
LibWeb: Introduce RecordingPainter to serialize painting commands This modification introduces a new layer to the painting process. The stacking context traversal no longer immediately calls the Gfx::Painter methods. Instead, it writes serialized painting commands into newly introduced RecordingPainter. Created list of commands is executed later to produce resulting bitmap. Producing painting command list will make it easier to add new optimizations: - It's simpler to check if the painting result is not visible in the viewport at the command level rather than during stacking context traversal. - Run painting in a separate thread. The painting thread can process serialized painting commands, while the main thread can work on the next paintable tree and safely invalidate the previous one. - As we consider GPU-accelerated painting support, it would be easier to back each painting command rather than constructing an alternative for the entire Gfx::Painter API.
2023-10-15 04:27:48 +02:00
public:
LibWeb: Fix "background-clip: text" for elements nested in scrollable Instead of carrying the display list for a mask in each command that might potentially be affected by "background-clip: text", this change introduces a new AddMask command that is applied once for all background layers within one box. The new AddMask command includes a rectangle for the mask destination that is translated by the corresponding scroll offset. Fixes https://github.com/LadybirdBrowser/ladybird/issues/857
2024-08-06 15:26:47 +03:00
void fill_rect(Gfx::IntRect const& rect, Color color);
LibWeb: Introduce RecordingPainter to serialize painting commands This modification introduces a new layer to the painting process. The stacking context traversal no longer immediately calls the Gfx::Painter methods. Instead, it writes serialized painting commands into newly introduced RecordingPainter. Created list of commands is executed later to produce resulting bitmap. Producing painting command list will make it easier to add new optimizations: - It's simpler to check if the painting result is not visible in the viewport at the command level rather than during stacking context traversal. - Run painting in a separate thread. The painting thread can process serialized painting commands, while the main thread can work on the next paintable tree and safely invalidate the previous one. - As we consider GPU-accelerated painting support, it would be easier to back each painting command rather than constructing an alternative for the entire Gfx::Painter API.
2023-10-15 04:27:48 +02:00
LibWeb: Merge FillPathUsingPaintStyle and FillPathUsingColor Use `Variant<PaintStyle, Gfx::Color>` in new `FillPath` instead of duplicating two almost identical display list items.
2025-08-02 21:16:51 +02:00
struct FillPathParams {
LibWeb: Port painting to use the new Skia-backed Gfx::Path SVG and and CSS border rendering now sits on top of SkPath instead of the old Gfx::DeprecatedPath. Due to an imperceptible (255, 255, 255) vs (255, 254, 255) color diff in one ref test, I changed that test to not depend on border rendering for a positive result, since that was incidental.
2024-08-09 14:00:10 +02:00
Gfx::Path path;
LibWeb: Merge FillPathUsingPaintStyle and FillPathUsingColor Use `Variant<PaintStyle, Gfx::Color>` in new `FillPath` instead of duplicating two almost identical display list items.
2025-08-02 21:16:51 +02:00
float opacity = 1.0f;
PaintStyleOrColor paint_style_or_color;
LibGfx: Move Gfx::Painter::WindingRule => Gfx::WindingRule
2024-06-05 10:21:28 +02:00
Gfx::WindingRule winding_rule = Gfx::WindingRule::EvenOdd;
LibWeb: Use `shape-rendering` to control anti aliasing for SVG paths Anti-aliasing is disabled if `shape-rendering` is set to `optimizeSpeed` or `crispEdges`.
2025-08-18 16:21:09 +01:00
ShouldAntiAlias should_anti_alias { ShouldAntiAlias::Yes };
LibWeb: Introduce RecordingPainter to serialize painting commands This modification introduces a new layer to the painting process. The stacking context traversal no longer immediately calls the Gfx::Painter methods. Instead, it writes serialized painting commands into newly introduced RecordingPainter. Created list of commands is executed later to produce resulting bitmap. Producing painting command list will make it easier to add new optimizations: - It's simpler to check if the painting result is not visible in the viewport at the command level rather than during stacking context traversal. - Run painting in a separate thread. The painting thread can process serialized painting commands, while the main thread can work on the next paintable tree and safely invalidate the previous one. - As we consider GPU-accelerated painting support, it would be easier to back each painting command rather than constructing an alternative for the entire Gfx::Painter API.
2023-10-15 04:27:48 +02:00
};
LibWeb: Merge FillPathUsingPaintStyle and FillPathUsingColor Use `Variant<PaintStyle, Gfx::Color>` in new `FillPath` instead of duplicating two almost identical display list items.
2025-08-02 21:16:51 +02:00
void fill_path(FillPathParams params);
LibWeb: Introduce RecordingPainter to serialize painting commands This modification introduces a new layer to the painting process. The stacking context traversal no longer immediately calls the Gfx::Painter methods. Instead, it writes serialized painting commands into newly introduced RecordingPainter. Created list of commands is executed later to produce resulting bitmap. Producing painting command list will make it easier to add new optimizations: - It's simpler to check if the painting result is not visible in the viewport at the command level rather than during stacking context traversal. - Run painting in a separate thread. The painting thread can process serialized painting commands, while the main thread can work on the next paintable tree and safely invalidate the previous one. - As we consider GPU-accelerated painting support, it would be easier to back each painting command rather than constructing an alternative for the entire Gfx::Painter API.
2023-10-15 04:27:48 +02:00
LibWeb: Merge StrokePathUsingPaintStyle and StrokePathUsingColor Use `Variant<PaintStyle, Gfx::Color>` in new `StrokePath` instead of duplicating two almost identical display list items.
2025-08-02 20:04:12 +02:00
struct StrokePathParams {
LibWeb: Plumb svg stroking state to DisplayListPlayerSkia The state is still ignored there, so no behavior change, but this should make it fairly easy to actually implement complete stroking support for SVGs.
2024-11-21 15:09:31 -05:00
Gfx::Path::CapStyle cap_style;
Gfx::Path::JoinStyle join_style;
float miter_limit;
Vector<float> dash_array;
float dash_offset;
LibWeb: Port painting to use the new Skia-backed Gfx::Path SVG and and CSS border rendering now sits on top of SkPath instead of the old Gfx::DeprecatedPath. Due to an imperceptible (255, 255, 255) vs (255, 254, 255) color diff in one ref test, I changed that test to not depend on border rendering for a positive result, since that was incidental.
2024-08-09 14:00:10 +02:00
Gfx::Path path;
LibWeb: Merge StrokePathUsingPaintStyle and StrokePathUsingColor Use `Variant<PaintStyle, Gfx::Color>` in new `StrokePath` instead of duplicating two almost identical display list items.
2025-08-02 20:04:12 +02:00
float opacity = 1.0f;
PaintStyleOrColor paint_style_or_color;
LibWeb: Introduce RecordingPainter to serialize painting commands This modification introduces a new layer to the painting process. The stacking context traversal no longer immediately calls the Gfx::Painter methods. Instead, it writes serialized painting commands into newly introduced RecordingPainter. Created list of commands is executed later to produce resulting bitmap. Producing painting command list will make it easier to add new optimizations: - It's simpler to check if the painting result is not visible in the viewport at the command level rather than during stacking context traversal. - Run painting in a separate thread. The painting thread can process serialized painting commands, while the main thread can work on the next paintable tree and safely invalidate the previous one. - As we consider GPU-accelerated painting support, it would be easier to back each painting command rather than constructing an alternative for the entire Gfx::Painter API.
2023-10-15 04:27:48 +02:00
float thickness;
LibWeb: Use `shape-rendering` to control anti aliasing for SVG paths Anti-aliasing is disabled if `shape-rendering` is set to `optimizeSpeed` or `crispEdges`.
2025-08-18 16:21:09 +01:00
ShouldAntiAlias should_anti_alias { ShouldAntiAlias::Yes };
LibWeb: Introduce RecordingPainter to serialize painting commands This modification introduces a new layer to the painting process. The stacking context traversal no longer immediately calls the Gfx::Painter methods. Instead, it writes serialized painting commands into newly introduced RecordingPainter. Created list of commands is executed later to produce resulting bitmap. Producing painting command list will make it easier to add new optimizations: - It's simpler to check if the painting result is not visible in the viewport at the command level rather than during stacking context traversal. - Run painting in a separate thread. The painting thread can process serialized painting commands, while the main thread can work on the next paintable tree and safely invalidate the previous one. - As we consider GPU-accelerated painting support, it would be easier to back each painting command rather than constructing an alternative for the entire Gfx::Painter API.
2023-10-15 04:27:48 +02:00
};
LibWeb: Merge StrokePathUsingPaintStyle and StrokePathUsingColor Use `Variant<PaintStyle, Gfx::Color>` in new `StrokePath` instead of duplicating two almost identical display list items.
2025-08-02 20:04:12 +02:00
void stroke_path(StrokePathParams);
LibWeb: Introduce RecordingPainter to serialize painting commands This modification introduces a new layer to the painting process. The stacking context traversal no longer immediately calls the Gfx::Painter methods. Instead, it writes serialized painting commands into newly introduced RecordingPainter. Created list of commands is executed later to produce resulting bitmap. Producing painting command list will make it easier to add new optimizations: - It's simpler to check if the painting result is not visible in the viewport at the command level rather than during stacking context traversal. - Run painting in a separate thread. The painting thread can process serialized painting commands, while the main thread can work on the next paintable tree and safely invalidate the previous one. - As we consider GPU-accelerated painting support, it would be easier to back each painting command rather than constructing an alternative for the entire Gfx::Painter API.
2023-10-15 04:27:48 +02:00
void draw_ellipse(Gfx::IntRect const& a_rect, Color color, int thickness);
LibWeb: Remove unused blend mode param in FillEllipse painting command
2024-04-20 10:20:01 +02:00
void fill_ellipse(Gfx::IntRect const& a_rect, Color color);
LibWeb: Introduce RecordingPainter to serialize painting commands This modification introduces a new layer to the painting process. The stacking context traversal no longer immediately calls the Gfx::Painter methods. Instead, it writes serialized painting commands into newly introduced RecordingPainter. Created list of commands is executed later to produce resulting bitmap. Producing painting command list will make it easier to add new optimizations: - It's simpler to check if the painting result is not visible in the viewport at the command level rather than during stacking context traversal. - Run painting in a separate thread. The painting thread can process serialized painting commands, while the main thread can work on the next paintable tree and safely invalidate the previous one. - As we consider GPU-accelerated painting support, it would be easier to back each painting command rather than constructing an alternative for the entire Gfx::Painter API.
2023-10-15 04:27:48 +02:00
LibWeb: Fix "background-clip: text" for elements nested in scrollable Instead of carrying the display list for a mask in each command that might potentially be affected by "background-clip: text", this change introduces a new AddMask command that is applied once for all background layers within one box. The new AddMask command includes a rectangle for the mask destination that is translated by the corresponding scroll offset. Fixes https://github.com/LadybirdBrowser/ladybird/issues/857
2024-08-06 15:26:47 +03:00
void fill_rect_with_linear_gradient(Gfx::IntRect const& gradient_rect, LinearGradientData const& data);
void fill_rect_with_conic_gradient(Gfx::IntRect const& rect, ConicGradientData const& data, Gfx::IntPoint const& position);
void fill_rect_with_radial_gradient(Gfx::IntRect const& rect, RadialGradientData const& data, Gfx::IntPoint center, Gfx::IntSize size);
LibWeb: Introduce RecordingPainter to serialize painting commands This modification introduces a new layer to the painting process. The stacking context traversal no longer immediately calls the Gfx::Painter methods. Instead, it writes serialized painting commands into newly introduced RecordingPainter. Created list of commands is executed later to produce resulting bitmap. Producing painting command list will make it easier to add new optimizations: - It's simpler to check if the painting result is not visible in the viewport at the command level rather than during stacking context traversal. - Run painting in a separate thread. The painting thread can process serialized painting commands, while the main thread can work on the next paintable tree and safely invalidate the previous one. - As we consider GPU-accelerated painting support, it would be easier to back each painting command rather than constructing an alternative for the entire Gfx::Painter API.
2023-10-15 04:27:48 +02:00
void draw_rect(Gfx::IntRect const& rect, Color color, bool rough = false);
LibWeb+LibGfx: Use GPU backend for <canvas> This is implemented by using a GPU-accelerated surface for <canvas> when a GPU context is available. A side effect of this change is that all canvas modifications have to be performed through Gfx::Painter, and whenever its content has to be accessed, we need to take a snapshot of the corresponding GPU surface. A new DrawPaintingSurface display list command is introduced to allow cheap blitting of canvas content without having to read GPU surface content into RAM.
2024-09-25 15:44:58 +02:00
void draw_painting_surface(Gfx::IntRect const& dst_rect, NonnullRefPtr<Gfx::PaintingSurface>, Gfx::IntRect const& src_rect, Gfx::ScalingMode scaling_mode = Gfx::ScalingMode::NearestNeighbor);
LibWeb: Do not deform bitmaps partially outside the img-box Instead of trying to manually determine which parts of a bitmap fall within the box of the `<img>` element, just draw the whole bitmap and let Skia clip the draw-area to the correct rectangle. This fixes a bug where the entire bitmap was squashed into the rectangle of the image box instead of being clipped. With this change, image rendering is now correct enough to import some of the WPT tests for object-fit and object-position. To get some good coverage I have imported all tests for the `<img>` tag. I also wanted to import a subset of the tests for the `<object>` tag, since those are passing as well now. Unfortunately, they are flaky for unknown reasons. This is the second attempt at this bugfix. The prior one was e055927ead and broke image rendering whenever the page was scrolled. It has subsequently been reverted in 16b14273d1. Hopefully this time it is not horribly broken.
2025-02-04 21:51:51 +01:00
void draw_scaled_immutable_bitmap(Gfx::IntRect const& dst_rect, Gfx::IntRect const& clip_rect, Gfx::ImmutableBitmap const& bitmap, Gfx::ScalingMode scaling_mode = Gfx::ScalingMode::NearestNeighbor);
LibWeb: Introduce RecordingPainter to serialize painting commands This modification introduces a new layer to the painting process. The stacking context traversal no longer immediately calls the Gfx::Painter methods. Instead, it writes serialized painting commands into newly introduced RecordingPainter. Created list of commands is executed later to produce resulting bitmap. Producing painting command list will make it easier to add new optimizations: - It's simpler to check if the painting result is not visible in the viewport at the command level rather than during stacking context traversal. - Run painting in a separate thread. The painting thread can process serialized painting commands, while the main thread can work on the next paintable tree and safely invalidate the previous one. - As we consider GPU-accelerated painting support, it would be easier to back each painting command rather than constructing an alternative for the entire Gfx::Painter API.
2023-10-15 04:27:48 +02:00
LibWeb: Rearrange code such that a lot less files include `Command.h` With this change number of recompiled files after modification of `Command.h` goes down from >1000 to <100.
2025-07-10 19:24:30 +02:00
void draw_repeated_immutable_bitmap(Gfx::IntRect dst_rect, Gfx::IntRect clip_rect, NonnullRefPtr<Gfx::ImmutableBitmap const> bitmap, Gfx::ScalingMode scaling_mode, bool repeat_x, bool repeat_y);
LibWeb: Add optimized painting command for repeated background With this change, instead of recording a display list item for each instance of a repeated background, a new DrawRepeatedImmutableBitmap type is used. This allows the painter to use optimized repeated image painting and, when the GPU backend is used, avoid re-uploading the image texture for each repetition. Some screenshot tests are affected, but there are no visible regressions. https://null.com/games/chainstaff works a lof faster with this change.
2024-07-23 15:36:28 +03:00
LibGfx: Move Gfx::Painter::LineStyle => Gfx::LineStyle
2024-06-05 10:25:10 +02:00
void draw_line(Gfx::IntPoint from, Gfx::IntPoint to, Color color, int thickness = 1, Gfx::LineStyle style = Gfx::LineStyle::Solid, Color alternate_color = Color::Transparent);
LibWeb: Introduce RecordingPainter to serialize painting commands This modification introduces a new layer to the painting process. The stacking context traversal no longer immediately calls the Gfx::Painter methods. Instead, it writes serialized painting commands into newly introduced RecordingPainter. Created list of commands is executed later to produce resulting bitmap. Producing painting command list will make it easier to add new optimizations: - It's simpler to check if the painting result is not visible in the viewport at the command level rather than during stacking context traversal. - Run painting in a separate thread. The painting thread can process serialized painting commands, while the main thread can work on the next paintable tree and safely invalidate the previous one. - As we consider GPU-accelerated painting support, it would be easier to back each painting command rather than constructing an alternative for the entire Gfx::Painter API.
2023-10-15 04:27:48 +02:00
LibWeb: Implement RecordingPainter::draw_text() via draw_text_run() To get away from the ancient (and buggy) text layout code in Gfx::Painter, we want to remove all the uses of Painter::draw_text(). As a first step towards this, we implement the draw_text() display list command in terms of the draw_text_run() command by performing the very simple necessary layout in draw_text() beforehand.
2024-06-21 07:50:48 +02:00
void draw_text(Gfx::IntRect const&, String, Gfx::Font const&, Gfx::TextAlignment, Color);
LibWeb: Introduce RecordingPainter to serialize painting commands This modification introduces a new layer to the painting process. The stacking context traversal no longer immediately calls the Gfx::Painter methods. Instead, it writes serialized painting commands into newly introduced RecordingPainter. Created list of commands is executed later to produce resulting bitmap. Producing painting command list will make it easier to add new optimizations: - It's simpler to check if the painting result is not visible in the viewport at the command level rather than during stacking context traversal. - Run painting in a separate thread. The painting thread can process serialized painting commands, while the main thread can work on the next paintable tree and safely invalidate the previous one. - As we consider GPU-accelerated painting support, it would be easier to back each painting command rather than constructing an alternative for the entire Gfx::Painter API.
2023-10-15 04:27:48 +02:00
// Streamlined text drawing routine that does no wrapping/elision/alignment.
LibWeb: Rename draw_text_run to draw_glyph_run in DisplayListRecorder For consistency with corresponding display list item name.
2025-07-26 16:31:22 +02:00
void draw_glyph_run(Gfx::FloatPoint baseline_start, Gfx::GlyphRun const& glyph_run, Color color, Gfx::IntRect const& rect, double scale, Gfx::Orientation);
LibWeb: Introduce RecordingPainter to serialize painting commands This modification introduces a new layer to the painting process. The stacking context traversal no longer immediately calls the Gfx::Painter methods. Instead, it writes serialized painting commands into newly introduced RecordingPainter. Created list of commands is executed later to produce resulting bitmap. Producing painting command list will make it easier to add new optimizations: - It's simpler to check if the painting result is not visible in the viewport at the command level rather than during stacking context traversal. - Run painting in a separate thread. The painting thread can process serialized painting commands, while the main thread can work on the next paintable tree and safely invalidate the previous one. - As we consider GPU-accelerated painting support, it would be easier to back each painting command rather than constructing an alternative for the entire Gfx::Painter API.
2023-10-15 04:27:48 +02:00
void add_clip_rect(Gfx::IntRect const& rect);
void translate(Gfx::IntPoint delta);
LibWeb: Don't produce save & restore commands for scroll frame id change This allows to substantially decrease display list length and save/restore churn during painting. Display list size comparison: | | Before | After | | ------------- | ------ | ------ | | basecamp.com | 19066 | 12248 | | ladybird.org | 8878 | 2220 | | react.dev | 39074 | 24382 |
2024-10-11 15:18:39 +02:00
void push_scroll_frame_id(Optional<i32> id);
void pop_scroll_frame_id();
LibWeb: Make AddClipRect display list item account for scroll offset Before this change AddClipRect was a "special" because it didn't respect scroll frame offset and was meant to be recorded using viewport-relative coordinates. The motivation behind this was to record a "final" clip rectangle computed by intersecting all clip rectangles used by a clip frame. The disadvantage of this approach is that it blocks us from implementing an optimisation to reuse display list if the only change is in the scroll offset, because any scroll offset change leads to invalidating all AddClipRect items within a list. This change aligns AddClipRect with the rest of display list items by making it account for scroll frame offset. It required discontinuing the recording of the intersection of all clip rectangles within a clip frame and instead producing an AddClipRect for each of them. A nice side effect is the removal of code that shifts clip rectangle by `enclosing_scroll_offset()` in a bunch of places, because now it happens automatically in `DisplayList::apply_scroll_offsets()`.
2024-08-10 14:24:25 +02:00
LibWeb: Expand ClipFrame into clip rectangles during display list replay Until now, every paint phase of every PaintableBox injected its own clipping sequence into the display list: ``` before_paint: Save AddClipRect (1) ...clip rectangles for each containing block with clip... AddClipRect (N) paint: ...paint phase items... after_paint: Restore ``` Because we ran that sequence for every phase of every box, Skia had to rebuild clip stack `paint_phases * paintable_boxes` times. Worse, usually most paint phases contribute no visible drawing at all, yet we still had to emit clipping items because `before_paint()` has no way to know that in advance. This change takes a different approach: - Clip information is now attached as metadata `ClipFrame` to each DisplayList item. - `DisplayListPlayer` groups consecutive commands that share a `ClipFrame`, applying the clip once at the start of the group and restoring it once at the end. Going from 10 ms to 5 ms in rasterization on Discord might not sound like much, but keep in mind that for 60fps we have 16 ms per frame and there is a lot more work besides display list rasterization we do in each frame. * https://discord.com/channels/1247070541085671459/1247090064480014443 - DisplayList items: 81844 -> 3671 - rasterize time: 10 ms -> 5 ms - record time: 5 ms -> 3 ms * https://github.com/LadybirdBrowser/ladybird - DisplayList items: 7902 -> 1176 - rasterize time: 4 ms -> 4 ms - record time: 3 ms -> 2 ms
2025-07-13 03:55:24 +02:00
void push_clip_frame(RefPtr<ClipFrame const>);
void pop_clip_frame();
LibWeb: Introduce RecordingPainter to serialize painting commands This modification introduces a new layer to the painting process. The stacking context traversal no longer immediately calls the Gfx::Painter methods. Instead, it writes serialized painting commands into newly introduced RecordingPainter. Created list of commands is executed later to produce resulting bitmap. Producing painting command list will make it easier to add new optimizations: - It's simpler to check if the painting result is not visible in the viewport at the command level rather than during stacking context traversal. - Run painting in a separate thread. The painting thread can process serialized painting commands, while the main thread can work on the next paintable tree and safely invalidate the previous one. - As we consider GPU-accelerated painting support, it would be easier to back each painting command rather than constructing an alternative for the entire Gfx::Painter API.
2023-10-15 04:27:48 +02:00
void save();
LibWeb/Painting: Add back `SaveLayer` command This reverts commit 552dd18696b1009d84d2a605491d9339c3e1da12.
2025-03-29 23:12:11 +01:00
void save_layer();
LibWeb: Introduce RecordingPainter to serialize painting commands This modification introduces a new layer to the painting process. The stacking context traversal no longer immediately calls the Gfx::Painter methods. Instead, it writes serialized painting commands into newly introduced RecordingPainter. Created list of commands is executed later to produce resulting bitmap. Producing painting command list will make it easier to add new optimizations: - It's simpler to check if the painting result is not visible in the viewport at the command level rather than during stacking context traversal. - Run painting in a separate thread. The painting thread can process serialized painting commands, while the main thread can work on the next paintable tree and safely invalidate the previous one. - As we consider GPU-accelerated painting support, it would be easier to back each painting command rather than constructing an alternative for the entire Gfx::Painter API.
2023-10-15 04:27:48 +02:00
void restore();
struct PushStackingContextParams {
float opacity;
LibWeb/CSS: Implement mix-blend-mode This adds support for the `mix-blend-mode` CSS property.
2025-01-22 09:50:49 +01:00
Gfx::CompositingAndBlendingOperator compositing_and_blending_operator;
bool isolate;
LibWeb: Don't encode painting limitations in RecordingPainter API The current set of stacking context commands do not encode the information needed to correctly paint the stacking context, instead, they're based on the limitations of the current CPU renderer. Stacking contexts should be able to be transformed by an arbitrary 3D transformation matrix, not just scaled from a source to a destination rect. The `_with_mask()` stacking context also should not be separate from the regular stacking context. ```c++ push_stacking_context( bool semitransparent_or_has_non_identity_transform, float opacity, Gfx::FloatRect const& source_rect, Gfx::FloatRect const& transformed_destination_rect, Gfx::IntPoint const& painter_location); pop_stacking_context( bool semitransparent_or_has_non_identity_transform, Gfx::Painter::ScalingMode scaling_mode); push_stacking_context_with_mask( Gfx::IntRect const& paint_rect); pop_stacking_context_with_mask( Gfx::IntRect const& paint_rect, RefPtr<Gfx::Bitmap> const& mask_bitmap, Gfx::Bitmap::MaskKind mask_kind, float opacity); ``` This patch replaces this APIs with just: ```c++ push_stacking_context( float opacity, bool is_fixed_position, Gfx::IntRect const& source_paintable_rect, Gfx::IntPoint post_transform_translation, CSS::ImageRendering image_rendering, StackingContextTransform transform, Optional<StackingContextMask> mask); pop_stacking_context() ``` And moves the implementation details into the executor, this should allow future backends to implement stacking contexts without these limitations.
2023-11-18 14:23:59 +00:00
StackingContextTransform transform;
LibWeb: Do not allocate mask bitmap for CSS "clip-path" property Instead, it could be applied directly as a clip path in Skia painter. As a side bonus, we get rid of some DeprecatedPath and AntiAliasingPainter usage.
2024-08-20 17:27:08 +02:00
Optional<Gfx::Path> clip_path = {};
LibWeb: Introduce RecordingPainter to serialize painting commands This modification introduces a new layer to the painting process. The stacking context traversal no longer immediately calls the Gfx::Painter methods. Instead, it writes serialized painting commands into newly introduced RecordingPainter. Created list of commands is executed later to produce resulting bitmap. Producing painting command list will make it easier to add new optimizations: - It's simpler to check if the painting result is not visible in the viewport at the command level rather than during stacking context traversal. - Run painting in a separate thread. The painting thread can process serialized painting commands, while the main thread can work on the next paintable tree and safely invalidate the previous one. - As we consider GPU-accelerated painting support, it would be easier to back each painting command rather than constructing an alternative for the entire Gfx::Painter API.
2023-10-15 04:27:48 +02:00
};
void push_stacking_context(PushStackingContextParams params);
LibWeb: Don't encode painting limitations in RecordingPainter API The current set of stacking context commands do not encode the information needed to correctly paint the stacking context, instead, they're based on the limitations of the current CPU renderer. Stacking contexts should be able to be transformed by an arbitrary 3D transformation matrix, not just scaled from a source to a destination rect. The `_with_mask()` stacking context also should not be separate from the regular stacking context. ```c++ push_stacking_context( bool semitransparent_or_has_non_identity_transform, float opacity, Gfx::FloatRect const& source_rect, Gfx::FloatRect const& transformed_destination_rect, Gfx::IntPoint const& painter_location); pop_stacking_context( bool semitransparent_or_has_non_identity_transform, Gfx::Painter::ScalingMode scaling_mode); push_stacking_context_with_mask( Gfx::IntRect const& paint_rect); pop_stacking_context_with_mask( Gfx::IntRect const& paint_rect, RefPtr<Gfx::Bitmap> const& mask_bitmap, Gfx::Bitmap::MaskKind mask_kind, float opacity); ``` This patch replaces this APIs with just: ```c++ push_stacking_context( float opacity, bool is_fixed_position, Gfx::IntRect const& source_paintable_rect, Gfx::IntPoint post_transform_translation, CSS::ImageRendering image_rendering, StackingContextTransform transform, Optional<StackingContextMask> mask); pop_stacking_context() ``` And moves the implementation details into the executor, this should allow future backends to implement stacking contexts without these limitations.
2023-11-18 14:23:59 +00:00
void pop_stacking_context();
LibWeb: Introduce RecordingPainter to serialize painting commands This modification introduces a new layer to the painting process. The stacking context traversal no longer immediately calls the Gfx::Painter methods. Instead, it writes serialized painting commands into newly introduced RecordingPainter. Created list of commands is executed later to produce resulting bitmap. Producing painting command list will make it easier to add new optimizations: - It's simpler to check if the painting result is not visible in the viewport at the command level rather than during stacking context traversal. - Run painting in a separate thread. The painting thread can process serialized painting commands, while the main thread can work on the next paintable tree and safely invalidate the previous one. - As we consider GPU-accelerated painting support, it would be easier to back each painting command rather than constructing an alternative for the entire Gfx::Painter API.
2023-10-15 04:27:48 +02:00
LibWeb: Fix scroll state refresh in cached display list for iframes 6507d23 introduced a bug when snapshot for iframe is saved in `PaintNestedDisplayList` and, since display lists are immutable, it's not possible to update before the next repaint. This change fixes the issue by moving `ScrollStateSnapshot` for nested display lists from `PaintNestedDisplayList` to `HashMap<NonnullRefPtr<DisplayList>, ScrollStateSnapshot>` that is placed into pending rendering task, making it possible to update snapshots for all display lists before the next repaint. This change doesn't have a test because it's really hard to make a ref test that will specifically check scenario when scroll offset of an iframe is advanced after display list is cached. We already have `Tests/LibWeb/Ref/input/scroll-iframe.html` but unfortunately it did not catch this bug. Fixes https://github.com/LadybirdBrowser/ladybird/issues/5486
2025-07-25 01:39:31 +02:00
void paint_nested_display_list(RefPtr<DisplayList> display_list, Gfx::IntRect rect);
LibWeb: Create clip and scroll frame trees separately for each navigable While introducing clip and scroll frame trees, I made a mistake by assuming that the paintable tree includes boxes from nested navigables. Therefore, this comment in the code was incorrect, and clip/scroll frames were simply not assigned for iframes: // NOTE: We only need to refresh the scroll state for traversables // because they are responsible for tracking the state of all // nested navigables. As a result, anything with "overflow: scroll" is currently not scrollable inside an iframe This change fixes that by ensuring clip and scroll frames are assigned and refreshed for each navigable. To achieve this, I had to modify the display list building process to record a separate display list for each navigable. This is necessary because scroll frame ids are local to a navigable, making it impossible to call `DisplayList::apply_scroll_offsets()` on a display list that contains ids from multiple navigables.
2024-08-08 14:17:54 +03:00
LibWeb: Delete BlitCornerClipping display list command Contrary to LibGfx, where corner clipping was implemented by sampling and blitting pixels under corners into a temporary bitmap, Skia allows us to simply apply a mask. As a result, we no longer need the BlitCornerClipping command, which has become a no-op. - SampleUnderCorners is renamed to AddRoundedRectClip - The optimization that skipped unnecessary blit and sample commands has been removed. However, this should not result in a performance regression because Skia seems to perform mask rasterization lazily.
2024-07-29 14:13:34 +03:00
void add_rounded_rect_clip(CornerRadii corner_radii, Gfx::IntRect border_rect, CornerClip corner_clip);
LibWeb: Fix "background-clip: text" for elements nested in scrollable Instead of carrying the display list for a mask in each command that might potentially be affected by "background-clip: text", this change introduces a new AddMask command that is applied once for all background layers within one box. The new AddMask command includes a rectangle for the mask destination that is translated by the corresponding scroll offset. Fixes https://github.com/LadybirdBrowser/ladybird/issues/857
2024-08-06 15:26:47 +03:00
void add_mask(RefPtr<DisplayList> display_list, Gfx::IntRect rect);
LibWeb: Introduce RecordingPainter to serialize painting commands This modification introduces a new layer to the painting process. The stacking context traversal no longer immediately calls the Gfx::Painter methods. Instead, it writes serialized painting commands into newly introduced RecordingPainter. Created list of commands is executed later to produce resulting bitmap. Producing painting command list will make it easier to add new optimizations: - It's simpler to check if the painting result is not visible in the viewport at the command level rather than during stacking context traversal. - Run painting in a separate thread. The painting thread can process serialized painting commands, while the main thread can work on the next paintable tree and safely invalidate the previous one. - As we consider GPU-accelerated painting support, it would be easier to back each painting command rather than constructing an alternative for the entire Gfx::Painter API.
2023-10-15 04:27:48 +02:00
LibGfx+LibWeb: Turn Gfx::Filter into a SkImageFilter wrapper
2025-05-11 12:44:54 +02:00
void apply_backdrop_filter(Gfx::IntRect const& backdrop_region, BorderRadiiData const& border_radii_data, Gfx::Filter const& backdrop_filter);
LibWeb: Introduce RecordingPainter to serialize painting commands This modification introduces a new layer to the painting process. The stacking context traversal no longer immediately calls the Gfx::Painter methods. Instead, it writes serialized painting commands into newly introduced RecordingPainter. Created list of commands is executed later to produce resulting bitmap. Producing painting command list will make it easier to add new optimizations: - It's simpler to check if the painting result is not visible in the viewport at the command level rather than during stacking context traversal. - Run painting in a separate thread. The painting thread can process serialized painting commands, while the main thread can work on the next paintable tree and safely invalidate the previous one. - As we consider GPU-accelerated painting support, it would be easier to back each painting command rather than constructing an alternative for the entire Gfx::Painter API.
2023-10-15 04:27:48 +02:00
LibWeb: Remove `params` suffix from `paint_{inner}outer_box_shadow`
2025-08-01 12:07:17 +02:00
void paint_outer_box_shadow(PaintBoxShadowParams params);
void paint_inner_box_shadow(PaintBoxShadowParams params);
LibGfx+LibWeb: Draw glyph runs with subpixel accuracy This improves the quality of our font rendering, especially when animations are involved. Relevant changes: * Skia fonts have their subpixel flag set, which means that individual glyphs are rendered at subpixel offsets causing glyph runs as a whole to look better. * Fragment offsets are no longer rounded to whole device pixels, and instead the floating point offset is kept. This allows us to pass through the floating point baseline position all the way to the Skia calls, which already expected that to be a float position. The `scrollable-contains-table.html` ref test needed different table headings since they would slightly inflate the column size in the test file, but not the reference.
2024-12-09 10:24:26 +01:00
void paint_text_shadow(int blur_radius, Gfx::IntRect bounding_rect, Gfx::IntRect text_rect, Gfx::GlyphRun const&, double glyph_run_scale, Color color, Gfx::FloatPoint draw_location);
LibWeb: Introduce RecordingPainter to serialize painting commands This modification introduces a new layer to the painting process. The stacking context traversal no longer immediately calls the Gfx::Painter methods. Instead, it writes serialized painting commands into newly introduced RecordingPainter. Created list of commands is executed later to produce resulting bitmap. Producing painting command list will make it easier to add new optimizations: - It's simpler to check if the painting result is not visible in the viewport at the command level rather than during stacking context traversal. - Run painting in a separate thread. The painting thread can process serialized painting commands, while the main thread can work on the next paintable tree and safely invalidate the previous one. - As we consider GPU-accelerated painting support, it would be easier to back each painting command rather than constructing an alternative for the entire Gfx::Painter API.
2023-10-15 04:27:48 +02:00
LibGfx: Delete DeprecatedPainter
2024-11-25 17:30:31 +04:00
void fill_rect_with_rounded_corners(Gfx::IntRect const& rect, Color color, CornerRadius top_left_radius, CornerRadius top_right_radius, CornerRadius bottom_right_radius, CornerRadius bottom_left_radius);
LibWeb: Fix "background-clip: text" for elements nested in scrollable Instead of carrying the display list for a mask in each command that might potentially be affected by "background-clip: text", this change introduces a new AddMask command that is applied once for all background layers within one box. The new AddMask command includes a rectangle for the mask destination that is translated by the corresponding scroll offset. Fixes https://github.com/LadybirdBrowser/ladybird/issues/857
2024-08-06 15:26:47 +03:00
void fill_rect_with_rounded_corners(Gfx::IntRect const& a_rect, Color color, int radius);
void fill_rect_with_rounded_corners(Gfx::IntRect const& a_rect, Color color, int top_left_radius, int top_right_radius, int bottom_right_radius, int bottom_left_radius);
LibWeb: Introduce RecordingPainter to serialize painting commands This modification introduces a new layer to the painting process. The stacking context traversal no longer immediately calls the Gfx::Painter methods. Instead, it writes serialized painting commands into newly introduced RecordingPainter. Created list of commands is executed later to produce resulting bitmap. Producing painting command list will make it easier to add new optimizations: - It's simpler to check if the painting result is not visible in the viewport at the command level rather than during stacking context traversal. - Run painting in a separate thread. The painting thread can process serialized painting commands, while the main thread can work on the next paintable tree and safely invalidate the previous one. - As we consider GPU-accelerated painting support, it would be easier to back each painting command rather than constructing an alternative for the entire Gfx::Painter API.
2023-10-15 04:27:48 +02:00
LibWeb/CSS: Implement the `scrollbar-color` property This allows the user to set the scrollbar thumb and track colors.
2025-05-26 22:36:12 +01:00
void paint_scrollbar(int scroll_frame_id, Gfx::IntRect gutter_rect, Gfx::IntRect thumb_rect, CSSPixelFraction scroll_size, Color thumb_color, Color track_color, bool vertical);
LibWeb: Update scroll thumb position by mutating display list A new display list item type named PaintScrollBar is introduced. Having a dedicated type for scroll bars allows the thumb position to be updated without rebuilding a display list. This was not possible with FillRectWithRoundedCorners that does not allow to tell whether it belongs to scroll thumb.
2024-08-17 18:56:56 +02:00
LibWeb: Don't allow SVG boxes to create a stacking context Prior to this change, SVGs were following the CSS painting order, which means SVG boxes could have established stacking context and be sorted by z-index. There is a section in the spec that defines what kind of SVG boxes should create a stacking context https://www.w3.org/TR/SVG2/render.html#EstablishingStackingContex Although this spec is marked as a draft and rendering order described in this spec does not match what other engines do. This spec issue comment has a good summary of what other engines actually do regarding painting order https://github.com/w3c/svgwg/issues/264#issuecomment-246432360 "as long as you're relying solely on the default z-index (which SVG1 does, by definition), nothing ever changes order when you apply opacity/filter/etc". This change aligns our implementation with other engines by forbidding SVGs to create a formatting context and painting them in order they are defined in tree tree.
2024-10-09 02:57:57 +02:00
void apply_opacity(float opacity);
LibWeb/CSS: Implement mix-blend-mode This adds support for the `mix-blend-mode` CSS property.
2025-01-22 09:50:49 +01:00
void apply_compositing_and_blending_operator(Gfx::CompositingAndBlendingOperator compositing_and_blending_operator);
LibGfx+LibWeb: Turn Gfx::Filter into a SkImageFilter wrapper
2025-05-11 12:44:54 +02:00
void apply_filter(Gfx::Filter filter);
LibWeb: Don't allow SVG boxes to create a stacking context Prior to this change, SVGs were following the CSS painting order, which means SVG boxes could have established stacking context and be sorted by z-index. There is a section in the spec that defines what kind of SVG boxes should create a stacking context https://www.w3.org/TR/SVG2/render.html#EstablishingStackingContex Although this spec is marked as a draft and rendering order described in this spec does not match what other engines do. This spec issue comment has a good summary of what other engines actually do regarding painting order https://github.com/w3c/svgwg/issues/264#issuecomment-246432360 "as long as you're relying solely on the default z-index (which SVG1 does, by definition), nothing ever changes order when you apply opacity/filter/etc". This change aligns our implementation with other engines by forbidding SVGs to create a formatting context and painting them in order they are defined in tree tree.
2024-10-09 02:57:57 +02:00
void apply_transform(Gfx::FloatPoint origin, Gfx::FloatMatrix4x4);
LibWeb: Save Gfx::ImmutableBitmap in ApplyBitmapMask display list item This allows to delete duplicated code between DisplayListPlayerSkia.cpp and ImmutableBitmap.cpp responsible for wrapping Gfx::Bitmap in SkImage.
2024-11-10 01:50:09 +01:00
void apply_mask_bitmap(Gfx::IntPoint origin, Gfx::ImmutableBitmap const&, Gfx::Bitmap::MaskKind);
LibWeb: Don't allow SVG boxes to create a stacking context Prior to this change, SVGs were following the CSS painting order, which means SVG boxes could have established stacking context and be sorted by z-index. There is a section in the spec that defines what kind of SVG boxes should create a stacking context https://www.w3.org/TR/SVG2/render.html#EstablishingStackingContex Although this spec is marked as a draft and rendering order described in this spec does not match what other engines do. This spec issue comment has a good summary of what other engines actually do regarding painting order https://github.com/w3c/svgwg/issues/264#issuecomment-246432360 "as long as you're relying solely on the default z-index (which SVG1 does, by definition), nothing ever changes order when you apply opacity/filter/etc". This change aligns our implementation with other engines by forbidding SVGs to create a formatting context and painting them in order they are defined in tree tree.
2024-10-09 02:57:57 +02:00
LibWeb: Rename RecordingPainter to DisplayListRecorder Use more widely recognized name among browser engine developers.
2024-06-23 18:40:10 +02:00
DisplayListRecorder(DisplayList&);
~DisplayListRecorder();
LibWeb: Introduce RecordingPainter to serialize painting commands This modification introduces a new layer to the painting process. The stacking context traversal no longer immediately calls the Gfx::Painter methods. Instead, it writes serialized painting commands into newly introduced RecordingPainter. Created list of commands is executed later to produce resulting bitmap. Producing painting command list will make it easier to add new optimizations: - It's simpler to check if the painting result is not visible in the viewport at the command level rather than during stacking context traversal. - Run painting in a separate thread. The painting thread can process serialized painting commands, while the main thread can work on the next paintable tree and safely invalidate the previous one. - As we consider GPU-accelerated painting support, it would be easier to back each painting command rather than constructing an alternative for the entire Gfx::Painter API.
2023-10-15 04:27:48 +02:00
LibWeb: Verify that save/restore are balanced within paintable Unbalanced save/restore within display list items recorded for a paintable means that some state only relevant for the paintable leaks to subsequent paintables, which is never expected behavior.
2025-07-06 18:07:43 +02:00
int m_save_nesting_level { 0 };
LibWeb: Make private `RecordingPainter::state()` Removes usage of `RecordingPainter::state()` and makes it private. No behavior change intended.
2023-12-16 14:06:47 +01:00
private:
LibWeb: Don't produce save & restore commands for scroll frame id change This allows to substantially decrease display list length and save/restore churn during painting. Display list size comparison: | | Before | After | | ------------- | ------ | ------ | | basecamp.com | 19066 | 12248 | | ladybird.org | 8878 | 2220 | | react.dev | 39074 | 24382 |
2024-10-11 15:18:39 +02:00
Vector<Optional<i32>> m_scroll_frame_id_stack;
LibWeb: Expand ClipFrame into clip rectangles during display list replay Until now, every paint phase of every PaintableBox injected its own clipping sequence into the display list: ``` before_paint: Save AddClipRect (1) ...clip rectangles for each containing block with clip... AddClipRect (N) paint: ...paint phase items... after_paint: Restore ``` Because we ran that sequence for every phase of every box, Skia had to rebuild clip stack `paint_phases * paintable_boxes` times. Worse, usually most paint phases contribute no visible drawing at all, yet we still had to emit clipping items because `before_paint()` has no way to know that in advance. This change takes a different approach: - Clip information is now attached as metadata `ClipFrame` to each DisplayList item. - `DisplayListPlayer` groups consecutive commands that share a `ClipFrame`, applying the clip once at the start of the group and restoring it once at the end. Going from 10 ms to 5 ms in rasterization on Discord might not sound like much, but keep in mind that for 60fps we have 16 ms per frame and there is a lot more work besides display list rasterization we do in each frame. * https://discord.com/channels/1247070541085671459/1247090064480014443 - DisplayList items: 81844 -> 3671 - rasterize time: 10 ms -> 5 ms - record time: 5 ms -> 3 ms * https://github.com/LadybirdBrowser/ladybird - DisplayList items: 7902 -> 1176 - rasterize time: 4 ms -> 4 ms - record time: 3 ms -> 2 ms
2025-07-13 03:55:24 +02:00
Vector<RefPtr<ClipFrame const>> m_clip_frame_stack;
LibWeb: Rename m_command_list to m_display_list in DisplayListRecorder
2025-08-01 04:24:09 +02:00
DisplayList& m_display_list;
LibWeb: Introduce RecordingPainter to serialize painting commands This modification introduces a new layer to the painting process. The stacking context traversal no longer immediately calls the Gfx::Painter methods. Instead, it writes serialized painting commands into newly introduced RecordingPainter. Created list of commands is executed later to produce resulting bitmap. Producing painting command list will make it easier to add new optimizations: - It's simpler to check if the painting result is not visible in the viewport at the command level rather than during stacking context traversal. - Run painting in a separate thread. The painting thread can process serialized painting commands, while the main thread can work on the next paintable tree and safely invalidate the previous one. - As we consider GPU-accelerated painting support, it would be easier to back each painting command rather than constructing an alternative for the entire Gfx::Painter API.
2023-10-15 04:27:48 +02:00
};
LibWeb: Rename RecordingPainter to DisplayListRecorder Use more widely recognized name among browser engine developers.
2024-06-23 18:40:10 +02:00
class DisplayListRecorderStateSaver {
LibWeb: Introduce RecordingPainter to serialize painting commands This modification introduces a new layer to the painting process. The stacking context traversal no longer immediately calls the Gfx::Painter methods. Instead, it writes serialized painting commands into newly introduced RecordingPainter. Created list of commands is executed later to produce resulting bitmap. Producing painting command list will make it easier to add new optimizations: - It's simpler to check if the painting result is not visible in the viewport at the command level rather than during stacking context traversal. - Run painting in a separate thread. The painting thread can process serialized painting commands, while the main thread can work on the next paintable tree and safely invalidate the previous one. - As we consider GPU-accelerated painting support, it would be easier to back each painting command rather than constructing an alternative for the entire Gfx::Painter API.
2023-10-15 04:27:48 +02:00
public:
LibWeb: Rename painter to recorder in DisplayListRecorderStateSaver
2025-08-01 04:59:06 +02:00
explicit DisplayListRecorderStateSaver(DisplayListRecorder& recorder)
: m_recorder(recorder)
LibWeb: Introduce RecordingPainter to serialize painting commands This modification introduces a new layer to the painting process. The stacking context traversal no longer immediately calls the Gfx::Painter methods. Instead, it writes serialized painting commands into newly introduced RecordingPainter. Created list of commands is executed later to produce resulting bitmap. Producing painting command list will make it easier to add new optimizations: - It's simpler to check if the painting result is not visible in the viewport at the command level rather than during stacking context traversal. - Run painting in a separate thread. The painting thread can process serialized painting commands, while the main thread can work on the next paintable tree and safely invalidate the previous one. - As we consider GPU-accelerated painting support, it would be easier to back each painting command rather than constructing an alternative for the entire Gfx::Painter API.
2023-10-15 04:27:48 +02:00
{
LibWeb: Rename painter to recorder in DisplayListRecorderStateSaver
2025-08-01 04:59:06 +02:00
m_recorder.save();
LibWeb: Introduce RecordingPainter to serialize painting commands This modification introduces a new layer to the painting process. The stacking context traversal no longer immediately calls the Gfx::Painter methods. Instead, it writes serialized painting commands into newly introduced RecordingPainter. Created list of commands is executed later to produce resulting bitmap. Producing painting command list will make it easier to add new optimizations: - It's simpler to check if the painting result is not visible in the viewport at the command level rather than during stacking context traversal. - Run painting in a separate thread. The painting thread can process serialized painting commands, while the main thread can work on the next paintable tree and safely invalidate the previous one. - As we consider GPU-accelerated painting support, it would be easier to back each painting command rather than constructing an alternative for the entire Gfx::Painter API.
2023-10-15 04:27:48 +02:00
}
LibWeb: Rename RecordingPainter to DisplayListRecorder Use more widely recognized name among browser engine developers.
2024-06-23 18:40:10 +02:00
~DisplayListRecorderStateSaver()
LibWeb: Introduce RecordingPainter to serialize painting commands This modification introduces a new layer to the painting process. The stacking context traversal no longer immediately calls the Gfx::Painter methods. Instead, it writes serialized painting commands into newly introduced RecordingPainter. Created list of commands is executed later to produce resulting bitmap. Producing painting command list will make it easier to add new optimizations: - It's simpler to check if the painting result is not visible in the viewport at the command level rather than during stacking context traversal. - Run painting in a separate thread. The painting thread can process serialized painting commands, while the main thread can work on the next paintable tree and safely invalidate the previous one. - As we consider GPU-accelerated painting support, it would be easier to back each painting command rather than constructing an alternative for the entire Gfx::Painter API.
2023-10-15 04:27:48 +02:00
{
LibWeb: Rename painter to recorder in DisplayListRecorderStateSaver
2025-08-01 04:59:06 +02:00
m_recorder.restore();
LibWeb: Introduce RecordingPainter to serialize painting commands This modification introduces a new layer to the painting process. The stacking context traversal no longer immediately calls the Gfx::Painter methods. Instead, it writes serialized painting commands into newly introduced RecordingPainter. Created list of commands is executed later to produce resulting bitmap. Producing painting command list will make it easier to add new optimizations: - It's simpler to check if the painting result is not visible in the viewport at the command level rather than during stacking context traversal. - Run painting in a separate thread. The painting thread can process serialized painting commands, while the main thread can work on the next paintable tree and safely invalidate the previous one. - As we consider GPU-accelerated painting support, it would be easier to back each painting command rather than constructing an alternative for the entire Gfx::Painter API.
2023-10-15 04:27:48 +02:00
}
private:
LibWeb: Rename painter to recorder in DisplayListRecorderStateSaver
2025-08-01 04:59:06 +02:00
DisplayListRecorder& m_recorder;
LibWeb: Introduce RecordingPainter to serialize painting commands This modification introduces a new layer to the painting process. The stacking context traversal no longer immediately calls the Gfx::Painter methods. Instead, it writes serialized painting commands into newly introduced RecordingPainter. Created list of commands is executed later to produce resulting bitmap. Producing painting command list will make it easier to add new optimizations: - It's simpler to check if the painting result is not visible in the viewport at the command level rather than during stacking context traversal. - Run painting in a separate thread. The painting thread can process serialized painting commands, while the main thread can work on the next paintable tree and safely invalidate the previous one. - As we consider GPU-accelerated painting support, it would be easier to back each painting command rather than constructing an alternative for the entire Gfx::Painter API.
2023-10-15 04:27:48 +02:00
};
}
Reference in a new issue Copy permalink