dmaax/ladybird
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
ladybird/Libraries/LibWeb/Painting/BorderRadiiData.cpp

22 lines
593 B
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-14 23:27:48 -03:00
/*
Meta: Update my e-mail address everywhere
2024-10-04 08:19:50 -03:00
* Copyright (c) 2020, Andreas Kling <andreas@ladybird.org>
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-14 23:27:48 -03:00
* Copyright (c) 2021-2023, Sam Atkins <atkinssj@serenityos.org>
*
* SPDX-License-Identifier: BSD-2-Clause
*/
#include <LibWeb/Painting/BorderRadiiData.h>
LibWeb: Rename PaintContext to DisplayListRecordingContext PaintContext dates back to a time when display lists didn't exist and it truly represented "paint context". Renaming it to better align with its current role.
2025-07-31 18:07:26 -03:00
#include <LibWeb/Painting/DisplayListRecordingContext.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-14 23:27:48 -03:00
namespace Web::Painting {
LibWeb: Separate device pixel conversion helpers from PaintContext In the upcoming change, device pixel conversion of ClipFrame will happen during display list replay, where PaintContext is not available, so let’s move it out of PaintContext.
2025-07-12 22:54:55 -03:00
CornerRadius BorderRadiusData::as_corner(DevicePixelConverter const& device_pixel_scale) const
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-14 23:27:48 -03:00
{
LibGfx: Delete DeprecatedPainter
2024-11-25 10:30:31 -03:00
return CornerRadius {
LibWeb: Separate device pixel conversion helpers from PaintContext In the upcoming change, device pixel conversion of ClipFrame will happen during display list replay, where PaintContext is not available, so let’s move it out of PaintContext.
2025-07-12 22:54:55 -03:00
device_pixel_scale.floored_device_pixels(horizontal_radius).value(),
device_pixel_scale.floored_device_pixels(vertical_radius).value()
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-14 23:27:48 -03:00
};
}
}
Reference in a new issue Copy permalink