Title: [289205] trunk/Source/WebCore
- Revision
- 289205
- Author
- [email protected]
- Date
- 2022-02-07 03:40:25 -0800 (Mon, 07 Feb 2022)
Log Message
[LBSE] Suppress non-foreground paint phases for SVG shapes & images
https://bugs.webkit.org/show_bug.cgi?id=236189
Reviewed by Rob Buis.
Suppress all paint phases except PaintPhase::Foreground for SVG primitives
such as paths, rects, images, etc. - all but RenderSVGContainer. We still
have to propagate the paint phases down the SVG render tree through the
container hierachy, as there could be <foreignObject> elements that do
need all paint phases.
If this ever turns out as bottleneck we can keep track of the presence
of <foreignObject> elements in a SVG subtree and only selectively propagate
the paint phases to those leafs that need them.
This optimization was used and tested with all SVG pixel tests in
the downstream branch -- so it's well tested that this works fine.
Covered by existing tests, no change in behaviour.
* rendering/RenderLayer.cpp:
(WebCore::RenderLayer::paintForegroundForFragments):
Modified Paths
Diff
Modified: trunk/Source/WebCore/ChangeLog (289204 => 289205)
--- trunk/Source/WebCore/ChangeLog 2022-02-07 11:36:31 UTC (rev 289204)
+++ trunk/Source/WebCore/ChangeLog 2022-02-07 11:40:25 UTC (rev 289205)
@@ -1,5 +1,30 @@
2022-02-07 Nikolas Zimmermann <[email protected]>
+ [LBSE] Suppress non-foreground paint phases for SVG shapes & images
+ https://bugs.webkit.org/show_bug.cgi?id=236189
+
+ Reviewed by Rob Buis.
+
+ Suppress all paint phases except PaintPhase::Foreground for SVG primitives
+ such as paths, rects, images, etc. - all but RenderSVGContainer. We still
+ have to propagate the paint phases down the SVG render tree through the
+ container hierachy, as there could be <foreignObject> elements that do
+ need all paint phases.
+
+ If this ever turns out as bottleneck we can keep track of the presence
+ of <foreignObject> elements in a SVG subtree and only selectively propagate
+ the paint phases to those leafs that need them.
+
+ This optimization was used and tested with all SVG pixel tests in
+ the downstream branch -- so it's well tested that this works fine.
+
+ Covered by existing tests, no change in behaviour.
+
+ * rendering/RenderLayer.cpp:
+ (WebCore::RenderLayer::paintForegroundForFragments):
+
+2022-02-07 Nikolas Zimmermann <[email protected]>
+
[LBSE] Extend overflow/clip rect handling for SVG layers
https://bugs.webkit.org/show_bug.cgi?id=236188
Modified: trunk/Source/WebCore/rendering/RenderLayer.cpp (289204 => 289205)
--- trunk/Source/WebCore/rendering/RenderLayer.cpp 2022-02-07 11:36:31 UTC (rev 289204)
+++ trunk/Source/WebCore/rendering/RenderLayer.cpp 2022-02-07 11:40:25 UTC (rev 289205)
@@ -105,6 +105,7 @@
#include "RenderMarquee.h"
#include "RenderMultiColumnFlow.h"
#include "RenderReplica.h"
+#include "RenderSVGContainer.h"
#include "RenderSVGForeignObject.h"
#include "RenderSVGModelObject.h"
#include "RenderSVGResourceClipper.h"
@@ -3820,6 +3821,19 @@
bool selectionOnly = localPaintingInfo.paintBehavior.contains(PaintBehavior::SelectionOnly);
bool selectionAndBackgroundsOnly = localPaintingInfo.paintBehavior.contains(PaintBehavior::SelectionAndBackgroundsOnly);
+#if ENABLE(LAYER_BASED_SVG_ENGINE)
+ if (is<RenderSVGModelObject>(renderer()) && !is<RenderSVGContainer>(renderer())) {
+ // SVG containers need to propagate paint phases. This could be saved if we remember somewhere if a SVG subtree
+ // contains e.g. RenderSVGForeignObject objects that do need the individual paint phases. For SVG shapes & SVG images
+ // we can avoid the multiple paintForegroundForFragmentsWithPhase() calls.
+ if (selectionOnly || selectionAndBackgroundsOnly)
+ return;
+
+ paintForegroundForFragmentsWithPhase(PaintPhase::Foreground, layerFragments, context, localPaintingInfo, localPaintBehavior, subtreePaintRootForRenderer);
+ return;
+ }
+#endif
+
if (!selectionOnly)
paintForegroundForFragmentsWithPhase(PaintPhase::ChildBlockBackgrounds, layerFragments, context, localPaintingInfo, localPaintBehavior, subtreePaintRootForRenderer);
_______________________________________________
webkit-changes mailing list
[email protected]
https://lists.webkit.org/mailman/listinfo/webkit-changes
