More targeted resource-switching mechanism for SVG selection painting

third_party/WebKit/Source/core/layout/svg/SVGResourcesCache.cpp

Index: third_party/WebKit/Source/core/layout/svg/SVGResourcesCache.cpp
diff --git a/third_party/WebKit/Source/core/layout/svg/SVGResourcesCache.cpp b/third_party/WebKit/Source/core/layout/svg/SVGResourcesCache.cpp
index b2a4e9c9823631c9a19ca61b6efccea001f6bba5..dc9cdff976402988c24be236fe841681199c2aaf 100644
--- a/third_party/WebKit/Source/core/layout/svg/SVGResourcesCache.cpp
+++ b/third_party/WebKit/Source/core/layout/svg/SVGResourcesCache.cpp
@@ -186,4 +186,24 @@ void SVGResourcesCache::ClientDestroyed(LayoutObject* layout_object) {
   cache.RemoveResourcesFromLayoutObject(layout_object);
 }
 
+SVGResourcesCache::TemporaryStyleScope::TemporaryStyleScope(
+    LayoutObject& layout_object,
+    const ComputedStyle& style,
+    const ComputedStyle& temporary_style)
+    : layout_object_(layout_object),
+      original_style_(style),
+      styles_are_equal_(style == temporary_style) {
+  SwitchTo(temporary_style);
+}
+
+void SVGResourcesCache::TemporaryStyleScope::SwitchTo(
+    const ComputedStyle& style) {
+  DCHECK(LayoutObjectCanHaveResources(&layout_object_));
+  if (styles_are_equal_)
+    return;
+  SVGResourcesCache& cache = ResourcesCache(layout_object_.GetDocument());
+  cache.RemoveResourcesFromLayoutObject(&layout_object_);
+  cache.AddResourcesFromLayoutObject(&layout_object_, style);

[Stephen Chennney, 2017/04/28 16:16:40]

A non-trivial chunk of invalidation logic is gone now. I presume that's a good
things because we do not want any invalidation for this style change. Am I
right?

[fs, 2017/04/28 18:16:34]

That is correct. Optimally we'd like to just produce fill/stroke (as needed)
from the selection style and use that - without any side-effects. As things are
right now, we rely on the 1:1 mapping LayoutObject<->SVGResources, and this is
submerged in the "fetch <paint>" code (i.e goes through the HashMap), so we need
to swap out the SVGResources. (Unfortunately this swaps out more than we'd want,
hence the dependent CLs.)
The invalidation bit on the other hand does us no good (since we're not actually
mutating the element/LayoutObject.)

+}
+
 }  // namespace blink