[LBSE] Handle RenderSVGShape in SVGRenderSupport::applyStrokeStyleToContext()

• Component: SVG
• Status: RESOLVED FIXED

[Nikolas Zimmermann]

[LBSE] Handle RenderSVGShape in SVGRenderSupport::applyStrokeStyleToContext()

[Nikolas Zimmermann]

Created attachment 450763 [details]
Patch, v1

[Darin Adler]

Comment on attachment 450763 [details]
Patch, v1

Checking in untested code is worrisome but I trust this will be tested once we switch on this new engine

[Nikolas Zimmermann]

(In reply to Darin Adler from comment #2)
> Comment on attachment 450763 [details]
> Patch, v1
> 
> Checking in untested code is worrisome but I trust this will be tested once
> we switch on this new engine

Thanks a lot Darin, it's highly appreciated!

I do hope things come in place soon that it makes sense to start running tests with LBSE enabled. When enough is upstreamed, so that first tests have a chance to pass we should talk about the best way to run LBSE enable builds/tests.

A possible solution is to deploy dedicated EWS workers that run with --layer-based-svg-engine -- would be easy to setup for Igalia folks for WPE/Gtk. Does that work for Apple too?

In the short-term feature, I plan to introduce a decision logic which selectively turns on LBSE if a given SVG document fragment adheres to certain criteria (e.g. no text/images in document, no clipping, etc.). This allows us to bring up LBSE in parallel to using legacy SVG as fallback and get test coverage early on -- simple documents would be rendered using LBSE, more complex ones with the legacy engine. This should hopefully address your concerns :-)

If you wonder about the current status of the work:

I will post a minimal patch series soon that will enable <rect> painting in LBSE. No container support yet, therefore only direct <rect> children of the outermost <svg> element can be painted -- a basic set of features to start with on purpose. Besides the lack of containers and other SVG primitives, there is no transform support yet: CSS/SVG transform integration with RenderLayer(Backing) is left out on purpose, as it can be introduced as separated patch series. 

After containers and (2D) transform support is in-place, we're only a few steps away before it finally makes sense to enable testing and before we can replace 'rely on trust' by 'rely on test progressions' :-)

[Nikolas Zimmermann]

Committed r289163 (246859@trunk): <https://commits.webkit.org/246859@trunk>

[Radar WebKit Bug Importer]

<rdar://problem/88531964>