Bug 12207

Summary: RenderSVGContainer should be split into multiple classes
Product: WebKit Reporter: Eric Seidel (no email) <eric>
Component: SVGAssignee: Nobody <webkit-unassigned>
Status: RESOLVED FIXED    
Severity: Normal CC: mjs, rwlbuis
Priority: P2    
Version: 420+   
Hardware: Mac   
OS: OS X 10.4   
Bug Depends on:    
Bug Blocks: 5940, 9752, 10526, 11976, 12221, 13981, 14051    
Attachments:
Description Flags
First attempt
mjs: review-
Work in progress
none
Split out RenderSVGRoot eric: review+

Eric Seidel (no email)
Reported 2007-01-11 00:56:15 PST
RenderSVGContainer should be split into two classes, one for SVG and one for G The current implementation is confusing at times and has lead to bugs like http://bugs.webkit.org/show_bug.cgi?id=12201
Attachments
First attempt (16.57 KB, patch)
2007-01-12 12:45 PST, Rob Buis
mjs: review-
Work in progress (31.63 KB, patch)
2007-06-12 15:57 PDT, Rob Buis
no flags
Split out RenderSVGRoot (38.88 KB, patch)
2007-06-12 17:08 PDT, Rob Buis
eric: review+
Rob Buis
Comment 1 2007-01-12 12:45:39 PST
Created attachment 12397 [details] First attempt Thi is not the final patch, and lots of test results will change (I guess all SVG results). I hope I get some feedback on the code and names I picked. Cheers, Rob.
Eric Seidel (no email)
Comment 2 2007-01-14 22:00:42 PST
We may need more than 2. Here are all the SVG containers I can think of, grouped by behavior: Have a viewBox and establish a viewPort: <svg> - new SVGRenderRoot <image> - RenderSVGImage <foreignObject> - RenderSVGForeignObject No viewbox, sometimes establishes a viewport: <symbol> - only when referenced by <use>, the logic should probably be in the <use> renderer(s) Has viewbox, but does not establish a viewport: <pattern> <marker> Neither of these draw their content directly. Has no viewport: <defs> - does not draw its content directly, but probably should have a renderer to allow proper style resolution of its kids (right now it has no renderer) <g> - should probably be RenderSVGContainer <view> also has a viewBox, but it's never drawn, so we don't need a renderer for it. I propose adding 3 new container types in this bug: RenderSVGRoot - for <svg>, is a RenderBlock, only trickiness occurs when inside another <svg> RenderSVGGroup - for <g>, only supports localTransform RenderSVGUseable - for <symbol>, <pattern>, <marker>, viewbox is simply ignored for <symbol>, does not draw content via normal paint() method. Optionally, you could also make <defs> a RenderSVGUsable, although then maybe it should be called RenderSVGHidden, not sure.
Eric Seidel (no email)
Comment 3 2007-01-14 22:15:48 PST
I forgot <mask> as well, that should also be part of the <symbol>, <pattern>, <marker> group, IMO.
Eric Seidel (no email)
Comment 4 2007-01-14 23:10:28 PST
Now that bug 12210, I should note that only the new RenderSVGRoot class will need to have the changes introduced in 12210.
Maciej Stachowiak
Comment 5 2007-01-15 01:52:09 PST
Comment on attachment 12397 [details] First attempt r- for now based on Eric's comments
Rob Buis
Comment 6 2007-06-05 00:43:36 PDT
(In reply to comment #4) > Now that bug 12210, I should note that only the new RenderSVGRoot class will > need to have the changes introduced in 12210. I'll give this another go, on the feature_branch. If anybody was working on it already, let me know, we should coordinate it. Cheers, Rob.
Eric Seidel (no email)
Comment 7 2007-06-06 03:10:40 PDT
Anyone working on this bug (i.e. rob) should be aware of the patch attached to: http://bugs.webkit.org/show_bug.cgi?id=14012 That patch includes some small changes which try to make it obvious what sections of RenderSVGContainer already have special-case code for the <svg> root element. The goal of splitting out a RenderSVGRoot class would be to remove those special cases from RenderSVGGroup (or RenderSVGContainer) so that RenderSVGContainer can only worry about being inside other SVG content, and RenderSVGRoot can worry about all the issues of mixing with other non-SVG content.
Rob Buis
Comment 8 2007-06-12 15:56:00 PDT
(In reply to comment #7) > Anyone working on this bug (i.e. rob) should be aware of the patch attached to: > http://bugs.webkit.org/show_bug.cgi?id=14012 I am assuming your remark is about trunk. The work will go to feature_branch and there the patch seems to be applied, so no problem. Cheers, Rob.
Rob Buis
Comment 9 2007-06-12 15:57:48 PDT
Created attachment 14987 [details] Work in progress This is just work in progress, a first split to RenderSVGRoot, no regressions. Cheers, Rob.
Rob Buis
Comment 10 2007-06-12 17:08:16 PDT
Created attachment 14988 [details] Split out RenderSVGRoot A good first start. Cheers, Rob.
Eric Seidel (no email)
Comment 11 2007-06-13 16:09:08 PDT
Comment on attachment 14988 [details] Split out RenderSVGRoot Eventually we'll need a better solution to this: + // FIXME: All this setup should be done after attributesChanged, not here. + rootContainer->setViewBox(viewBox()); + rootContainer->setAlign(SVGPreserveAspectRatio::SVGPreserveAspectRatioType(preserveAspectRatio()->align())); + rootContainer->setSlice(preserveAspectRatio()->meetOrSlice() == SVGPreserveAspectRatio::SVG_MEETORSLICE_SLICE); We'll need to find a way to abstract a bunch of this code so it's not so copy/paste. It looks fine for a start. We'll need follow up patches to clean up these newly split classes.
Rob Buis
Comment 12 2007-06-13 16:26:17 PDT
Landed in r23509.
Note You need to log in before you can comment on or make changes to this bug.