Stowage/ladybird
2
0
Fork 0
mirror of https://github.com/LadybirdBrowser/ladybird.git synced 2025-11-04 23:30:59 +00:00
Code Issues Projects Releases Packages Wiki Activity
ladybird/Libraries/LibWeb/Painting/DisplayListPlayerSkia.h

75 lines
3.2 KiB
C
Raw Normal View History

LibWeb: Add Skia painting command executor This change introduces Skia painter available under a flag. It's not yet match capabilities of Gfx::Painter and is not ready to replace it. Motivation: - The current CPU painter is a performance bottleneck on most websites. Our own GPU painter implementation is very immature and has received relatively little attention. - There is ongoing effort on building painter that supports affine transforms (AffineCommandExecutorCPU) but it is far from being on par with the default CPU painter. Skia will allow us to immediately get full transformation support for all painting commands. GPU painting: I experimented with Ganesh GPU-backend, however profiling revealed that without sharing viewport texture between WebContent and Browser processes, it won't bring much performance improvement compared to CPU-backend. Therefore, I decided to keep this PR focused on implementing most of painting commands and switch to GPU-backend in future changes. Text rendring: Skia painter uses glyph bitmaps produced by LibGfx. Using Skia for text rendering will require large refactoring of the font rendering subsystem. Currently, it's impossible to construct SkFont right before rendering because Gfx::VectorFont can't be serialized back into sequence of bytes. There is a problem with ugly include paths like: `#include <core/SkBitmap.h>`. I would prefer to have skia prefix in the path. There was an attempt to fix that but PR was rejected https://github.com/microsoft/vcpkg/pull/32660 Regressions compared to Gfx::Painter: - DrawText is not implemented - PaintTextShadow is not implemented - PaintRadialGradient and PaintLinearGradient do not support "transition hints" and repeat length - PaintConicGradient is not implemented - DrawTriangleWave is not implemented - DrawLine does not account for line style property - DrawScaledBitmap and DrawScaledImmutableBitmap do not account for scaling mode property
2024-06-10 14:22:04 +03:00
/*
* Copyright (c) 2024, Aliaksandr Kalenik <kalenik.aliaksandr@gmail.com>
*
* SPDX-License-Identifier: BSD-2-Clause
*/
#pragma once
LibWeb+LibGfx: Move class that represents Skia GPU context to LibGfx This is required to share GPU context creation code between display list player, which resides in LibWeb, and PainterSkia, which handles <canvas> painting.
2024-09-19 22:34:53 +02:00
#include <LibGfx/SkiaBackendContext.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/Painting/Command.h>
#include <LibWeb/Painting/DisplayList.h>
LibWeb: Rename RecordingPainter to DisplayListRecorder Use more widely recognized name among browser engine developers.
2024-06-23 18:40:10 +02:00
#include <LibWeb/Painting/DisplayListRecorder.h>
LibWeb: Add Skia painting command executor This change introduces Skia painter available under a flag. It's not yet match capabilities of Gfx::Painter and is not ready to replace it. Motivation: - The current CPU painter is a performance bottleneck on most websites. Our own GPU painter implementation is very immature and has received relatively little attention. - There is ongoing effort on building painter that supports affine transforms (AffineCommandExecutorCPU) but it is far from being on par with the default CPU painter. Skia will allow us to immediately get full transformation support for all painting commands. GPU painting: I experimented with Ganesh GPU-backend, however profiling revealed that without sharing viewport texture between WebContent and Browser processes, it won't bring much performance improvement compared to CPU-backend. Therefore, I decided to keep this PR focused on implementing most of painting commands and switch to GPU-backend in future changes. Text rendring: Skia painter uses glyph bitmaps produced by LibGfx. Using Skia for text rendering will require large refactoring of the font rendering subsystem. Currently, it's impossible to construct SkFont right before rendering because Gfx::VectorFont can't be serialized back into sequence of bytes. There is a problem with ugly include paths like: `#include <core/SkBitmap.h>`. I would prefer to have skia prefix in the path. There was an attempt to fix that but PR was rejected https://github.com/microsoft/vcpkg/pull/32660 Regressions compared to Gfx::Painter: - DrawText is not implemented - PaintTextShadow is not implemented - PaintRadialGradient and PaintLinearGradient do not support "transition hints" and repeat length - PaintConicGradient is not implemented - DrawTriangleWave is not implemented - DrawLine does not account for line style property - DrawScaledBitmap and DrawScaledImmutableBitmap do not account for scaling mode property
2024-06-10 14:22:04 +03:00
LibWeb+LibGfx: Move class that represents Skia GPU context to LibGfx This is required to share GPU context creation code between display list player, which resides in LibWeb, and PainterSkia, which handles <canvas> painting.
2024-09-19 22:34:53 +02:00
class GrDirectContext;
LibWeb+LibCore: Use Vulkan backend for Skia on Linux Skia now uses GPU-accelerated painting on Linux if Vulkan is available. Most of the performance gain is currently negated by reading the GPU backend back into RAM to pass it to the Browser process. In the future, this could be improved by sharing GPU-allocated memory across the Browser and WebContent processes.
2024-07-03 19:23:27 +02:00
LibWeb: Add Skia painting command executor This change introduces Skia painter available under a flag. It's not yet match capabilities of Gfx::Painter and is not ready to replace it. Motivation: - The current CPU painter is a performance bottleneck on most websites. Our own GPU painter implementation is very immature and has received relatively little attention. - There is ongoing effort on building painter that supports affine transforms (AffineCommandExecutorCPU) but it is far from being on par with the default CPU painter. Skia will allow us to immediately get full transformation support for all painting commands. GPU painting: I experimented with Ganesh GPU-backend, however profiling revealed that without sharing viewport texture between WebContent and Browser processes, it won't bring much performance improvement compared to CPU-backend. Therefore, I decided to keep this PR focused on implementing most of painting commands and switch to GPU-backend in future changes. Text rendring: Skia painter uses glyph bitmaps produced by LibGfx. Using Skia for text rendering will require large refactoring of the font rendering subsystem. Currently, it's impossible to construct SkFont right before rendering because Gfx::VectorFont can't be serialized back into sequence of bytes. There is a problem with ugly include paths like: `#include <core/SkBitmap.h>`. I would prefer to have skia prefix in the path. There was an attempt to fix that but PR was rejected https://github.com/microsoft/vcpkg/pull/32660 Regressions compared to Gfx::Painter: - DrawText is not implemented - PaintTextShadow is not implemented - PaintRadialGradient and PaintLinearGradient do not support "transition hints" and repeat length - PaintConicGradient is not implemented - DrawTriangleWave is not implemented - DrawLine does not account for line style property - DrawScaledBitmap and DrawScaledImmutableBitmap do not account for scaling mode property
2024-06-10 14:22:04 +03:00
namespace Web::Painting {
LibGfx+LibWeb: Reuse DisplayListPlayer and PaintingSurface when possible Previously, we were reinstantiating the DisplayListPlayer and PaintingSurface on every paint.
2025-01-29 10:24:57 +01:00
class DisplayListPlayerSkia final : public DisplayListPlayer {
LibWeb: Add Skia painting command executor This change introduces Skia painter available under a flag. It's not yet match capabilities of Gfx::Painter and is not ready to replace it. Motivation: - The current CPU painter is a performance bottleneck on most websites. Our own GPU painter implementation is very immature and has received relatively little attention. - There is ongoing effort on building painter that supports affine transforms (AffineCommandExecutorCPU) but it is far from being on par with the default CPU painter. Skia will allow us to immediately get full transformation support for all painting commands. GPU painting: I experimented with Ganesh GPU-backend, however profiling revealed that without sharing viewport texture between WebContent and Browser processes, it won't bring much performance improvement compared to CPU-backend. Therefore, I decided to keep this PR focused on implementing most of painting commands and switch to GPU-backend in future changes. Text rendring: Skia painter uses glyph bitmaps produced by LibGfx. Using Skia for text rendering will require large refactoring of the font rendering subsystem. Currently, it's impossible to construct SkFont right before rendering because Gfx::VectorFont can't be serialized back into sequence of bytes. There is a problem with ugly include paths like: `#include <core/SkBitmap.h>`. I would prefer to have skia prefix in the path. There was an attempt to fix that but PR was rejected https://github.com/microsoft/vcpkg/pull/32660 Regressions compared to Gfx::Painter: - DrawText is not implemented - PaintTextShadow is not implemented - PaintRadialGradient and PaintLinearGradient do not support "transition hints" and repeat length - PaintConicGradient is not implemented - DrawTriangleWave is not implemented - DrawLine does not account for line style property - DrawScaledBitmap and DrawScaledImmutableBitmap do not account for scaling mode property
2024-06-10 14:22:04 +03:00
public:
LibGfx+LibWeb: Reuse DisplayListPlayer and PaintingSurface when possible Previously, we were reinstantiating the DisplayListPlayer and PaintingSurface on every paint.
2025-01-29 10:24:57 +01:00
DisplayListPlayerSkia(RefPtr<Gfx::SkiaBackendContext>);
DisplayListPlayerSkia();
LibWeb: Cache compiled shaders for masks in DisplayListPlayerSkia By avoiding recompilation every time `apply_mask_bitmap()` is called, we save ~5 ms (20ms -> 15ms) in rendering of browser channel on Discord on my machine.
2025-07-09 04:12:39 +02:00
~DisplayListPlayerSkia();
LibWeb: Move display list command dispatch into player With this change display list player will be able to recurse into executing another display list, without having to construct new display list player. It is going to be useful in the upcoming changes to paint a mask from a display list owned by a command.
2024-07-24 16:48:32 +03:00
private:
LibGfx+LibWeb: Reuse DisplayListPlayer and PaintingSurface when possible Previously, we were reinstantiating the DisplayListPlayer and PaintingSurface on every paint.
2025-01-29 10:24:57 +01:00
void flush() override;
LibWeb: Remove stacking context painting failure handling CommandResult was needed by LibGfx display list player that could have failed to allocate a temporary bitmap for painting a stacking context with CSS transforms. This is no longer an issue with Skia painter, so we can delete CommandResult::SkipStackingContext handling path.
2024-07-24 13:55:15 +03:00
void draw_glyph_run(DrawGlyphRun const&) override;
void fill_rect(FillRect const&) override;
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(DrawPaintingSurface const&) override;
LibWeb: Remove stacking context painting failure handling CommandResult was needed by LibGfx display list player that could have failed to allocate a temporary bitmap for painting a stacking context with CSS transforms. This is no longer an issue with Skia painter, so we can delete CommandResult::SkipStackingContext handling path.
2024-07-24 13:55:15 +03:00
void draw_scaled_immutable_bitmap(DrawScaledImmutableBitmap const&) override;
void draw_repeated_immutable_bitmap(DrawRepeatedImmutableBitmap const&) override;
void add_clip_rect(AddClipRect const&) override;
void save(Save const&) override;
LibWeb/Painting: Add back `SaveLayer` command This reverts commit 552dd18696b1009d84d2a605491d9339c3e1da12.
2025-03-29 23:12:11 +01:00
void save_layer(SaveLayer const&) override;
LibWeb: Remove stacking context painting failure handling CommandResult was needed by LibGfx display list player that could have failed to allocate a temporary bitmap for painting a stacking context with CSS transforms. This is no longer an issue with Skia painter, so we can delete CommandResult::SkipStackingContext handling path.
2024-07-24 13:55:15 +03:00
void restore(Restore const&) override;
LibWeb: Remove translation from display list recorded state ...and add display list item that does translation instead. By doing that we no longer need to map each coordinate in display list by translation in recorder state.
2024-10-11 15:01:16 +02:00
void translate(Translate const&) override;
LibWeb: Remove stacking context painting failure handling CommandResult was needed by LibGfx display list player that could have failed to allocate a temporary bitmap for painting a stacking context with CSS transforms. This is no longer an issue with Skia painter, so we can delete CommandResult::SkipStackingContext handling path.
2024-07-24 13:55:15 +03:00
void push_stacking_context(PushStackingContext const&) override;
void pop_stacking_context(PopStackingContext const&) override;
void paint_linear_gradient(PaintLinearGradient const&) override;
void paint_outer_box_shadow(PaintOuterBoxShadow const&) override;
void paint_inner_box_shadow(PaintInnerBoxShadow const&) override;
void paint_text_shadow(PaintTextShadow const&) override;
void fill_rect_with_rounded_corners(FillRectWithRoundedCorners const&) override;
void fill_path_using_color(FillPathUsingColor const&) override;
void fill_path_using_paint_style(FillPathUsingPaintStyle const&) override;
void stroke_path_using_color(StrokePathUsingColor const&) override;
void stroke_path_using_paint_style(StrokePathUsingPaintStyle const&) override;
void draw_ellipse(DrawEllipse const&) override;
void fill_ellipse(FillEllipse const&) override;
void draw_line(DrawLine const&) override;
void apply_backdrop_filter(ApplyBackdropFilter const&) override;
void draw_rect(DrawRect const&) override;
void paint_radial_gradient(PaintRadialGradient const&) override;
void paint_conic_gradient(PaintConicGradient const&) override;
void draw_triangle_wave(DrawTriangleWave const&) override;
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(AddRoundedRectClip const&) override;
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(AddMask const&) override;
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
void paint_scrollbar(PaintScrollBar const&) override;
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
void paint_nested_display_list(PaintNestedDisplayList const&) override;
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(ApplyOpacity const&) override;
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_composite_and_blending_operator(ApplyCompositeAndBlendingOperator const&) override;
LibGfx+LibWeb: Turn Gfx::Filter into a SkImageFilter wrapper
2025-05-11 12:44:54 +02:00
void apply_filters(ApplyFilter const&) override;
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(ApplyTransform const&) override;
void apply_mask_bitmap(ApplyMaskBitmap const&) override;
LibWeb: Add Skia painting command executor This change introduces Skia painter available under a flag. It's not yet match capabilities of Gfx::Painter and is not ready to replace it. Motivation: - The current CPU painter is a performance bottleneck on most websites. Our own GPU painter implementation is very immature and has received relatively little attention. - There is ongoing effort on building painter that supports affine transforms (AffineCommandExecutorCPU) but it is far from being on par with the default CPU painter. Skia will allow us to immediately get full transformation support for all painting commands. GPU painting: I experimented with Ganesh GPU-backend, however profiling revealed that without sharing viewport texture between WebContent and Browser processes, it won't bring much performance improvement compared to CPU-backend. Therefore, I decided to keep this PR focused on implementing most of painting commands and switch to GPU-backend in future changes. Text rendring: Skia painter uses glyph bitmaps produced by LibGfx. Using Skia for text rendering will require large refactoring of the font rendering subsystem. Currently, it's impossible to construct SkFont right before rendering because Gfx::VectorFont can't be serialized back into sequence of bytes. There is a problem with ugly include paths like: `#include <core/SkBitmap.h>`. I would prefer to have skia prefix in the path. There was an attempt to fix that but PR was rejected https://github.com/microsoft/vcpkg/pull/32660 Regressions compared to Gfx::Painter: - DrawText is not implemented - PaintTextShadow is not implemented - PaintRadialGradient and PaintLinearGradient do not support "transition hints" and repeat length - PaintConicGradient is not implemented - DrawTriangleWave is not implemented - DrawLine does not account for line style property - DrawScaledBitmap and DrawScaledImmutableBitmap do not account for scaling mode property
2024-06-10 14:22:04 +03:00
bool would_be_fully_clipped_by_painter(Gfx::IntRect) const override;
LibGfx+LibWeb: Reuse DisplayListPlayer and PaintingSurface when possible Previously, we were reinstantiating the DisplayListPlayer and PaintingSurface on every paint.
2025-01-29 10:24:57 +01:00
RefPtr<Gfx::SkiaBackendContext> m_context;
LibWeb: Cache compiled shaders for masks in DisplayListPlayerSkia By avoiding recompilation every time `apply_mask_bitmap()` is called, we save ~5 ms (20ms -> 15ms) in rendering of browser channel on Discord on my machine.
2025-07-09 04:12:39 +02:00
struct CachedRuntimeEffects;
OwnPtr<CachedRuntimeEffects> m_cached_runtime_effects;
CachedRuntimeEffects& cached_runtime_effects();
LibWeb: Add Skia painting command executor This change introduces Skia painter available under a flag. It's not yet match capabilities of Gfx::Painter and is not ready to replace it. Motivation: - The current CPU painter is a performance bottleneck on most websites. Our own GPU painter implementation is very immature and has received relatively little attention. - There is ongoing effort on building painter that supports affine transforms (AffineCommandExecutorCPU) but it is far from being on par with the default CPU painter. Skia will allow us to immediately get full transformation support for all painting commands. GPU painting: I experimented with Ganesh GPU-backend, however profiling revealed that without sharing viewport texture between WebContent and Browser processes, it won't bring much performance improvement compared to CPU-backend. Therefore, I decided to keep this PR focused on implementing most of painting commands and switch to GPU-backend in future changes. Text rendring: Skia painter uses glyph bitmaps produced by LibGfx. Using Skia for text rendering will require large refactoring of the font rendering subsystem. Currently, it's impossible to construct SkFont right before rendering because Gfx::VectorFont can't be serialized back into sequence of bytes. There is a problem with ugly include paths like: `#include <core/SkBitmap.h>`. I would prefer to have skia prefix in the path. There was an attempt to fix that but PR was rejected https://github.com/microsoft/vcpkg/pull/32660 Regressions compared to Gfx::Painter: - DrawText is not implemented - PaintTextShadow is not implemented - PaintRadialGradient and PaintLinearGradient do not support "transition hints" and repeat length - PaintConicGradient is not implemented - DrawTriangleWave is not implemented - DrawLine does not account for line style property - DrawScaledBitmap and DrawScaledImmutableBitmap do not account for scaling mode property
2024-06-10 14:22:04 +03:00
};
}
Reference in a new issue Copy permalink