Bug 141463 - Streamline and simplify SVGSVGElement and related classes
Summary: Streamline and simplify SVGSVGElement and related classes
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: SVG (show other bugs)
Version: 528+ (Nightly build)
Hardware: All All
: P2 Normal
Assignee: Darin Adler
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-02-10 22:50 PST by Darin Adler
Modified: 2015-02-11 21:09 PST (History)
6 users (show)

See Also:


Attachments
Patch (64.17 KB, patch)
2015-02-10 23:12 PST, Darin Adler
no flags Details | Formatted Diff | Diff
Patch (64.16 KB, patch)
2015-02-11 08:19 PST, Darin Adler
koivisto: review+
Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Darin Adler 2015-02-10 22:50:42 PST
Streamline and simplify SVGSVGElement and related classes
Comment 1 Darin Adler 2015-02-10 23:12:42 PST
Created attachment 246375 [details]
Patch
Comment 2 Darin Adler 2015-02-11 08:19:32 PST
Created attachment 246392 [details]
Patch
Comment 3 Antti Koivisto 2015-02-11 10:01:30 PST
Comment on attachment 246392 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=246392&action=review

> Source/WebCore/svg/SVGSVGElement.cpp:67
> -    , m_timeContainer(SMILTimeContainer::create(this))
> +    , m_timeContainer(RefPtr<SMILTimeContainer>(SMILTimeContainer::create(this)).releaseNonNull())

Can't you just make SMILTimeContainer::create return a Ref? This is the only client.

> Source/WebCore/svg/SVGSVGElement.cpp:97
> +    static NeverDestroyed<AtomicString> defaultScriptType("text/ecmascript");

Consistent use of {} initialization might be nice for things like NeverDestroyed.

> Source/WebCore/svg/SVGSVGElement.cpp:369
> +    return SVGTransform { matrix };

This doesn't build without SVGTransform?
Comment 4 Said Abou-Hallawa 2015-02-11 10:45:00 PST
Comment on attachment 246392 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=246392&action=review

> Source/WebCore/svg/SVGSVGElement.cpp:253
> +    SVGGraphicsElement::parseAttribute(name, value);

Is this change making the code clearer? Can it affect the performance? Also all the parseAttribute functions above return bool expect SVGGraphicsElement::parseAttribute() which returns void. I think this looks inconsistent especially we do not use the returned bool value anymore.

> Source/WebCore/svg/SVGSVGElement.cpp:525
>  }

Why is this function here? Why can't it be added to FloatSize.h? If it can't be added, can't we implement it using the FloatSize::operator*()?

> Source/WebCore/svg/SVGSVGElement.cpp:537
> +        return root.contentBoxRect().size() / root.style().effectiveZoom();

Can't we say?
return root.contentBoxRect().size() * (1 / root.style().effectiveZoom());

> Source/WebCore/svg/SVGViewElement.cpp:62
> +    SVGElement::parseAttribute(name, value);

Is this change to make code clearer? Can't it return bool in case one wants to know if the attribute was parsed by this function or not? Can this change affect the performance?
Comment 5 Darin Adler 2015-02-11 11:52:43 PST
Comment on attachment 246392 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=246392&action=review

>> Source/WebCore/svg/SVGSVGElement.cpp:67
>> +    , m_timeContainer(RefPtr<SMILTimeContainer>(SMILTimeContainer::create(this)).releaseNonNull())
> 
> Can't you just make SMILTimeContainer::create return a Ref? This is the only client.

Yes, but I’m going to do even better in a follow-up patch and make it not even a reference counted object any more, so for now I’ll just leave it like this.

>> Source/WebCore/svg/SVGSVGElement.cpp:97
>> +    static NeverDestroyed<AtomicString> defaultScriptType("text/ecmascript");
> 
> Consistent use of {} initialization might be nice for things like NeverDestroyed.

Good point. I’ll use { } instead of () here.

>> Source/WebCore/svg/SVGSVGElement.cpp:253
>> +    SVGGraphicsElement::parseAttribute(name, value);
> 
> Is this change making the code clearer? Can it affect the performance? Also all the parseAttribute functions above return bool expect SVGGraphicsElement::parseAttribute() which returns void. I think this looks inconsistent especially we do not use the returned bool value anymore.

I plan to remove all those bool return values. I think the whole strategy of cascading booleans for attributes doesn’t provide any significant performance boost and is not worthwhile. I am planning on making this change across all of SVG. The current implementation is really wasteful, with HashSets just to preflight and decide whether to call through to base classes.

>> Source/WebCore/svg/SVGSVGElement.cpp:369
>> +    return SVGTransform { matrix };
> 
> This doesn't build without SVGTransform?

It doesn’t because the SVGTransform constructor is marked explicit. We could remove the explicit and remove this explicit type too.

>> Source/WebCore/svg/SVGSVGElement.cpp:525
>>  }
> 
> Why is this function here? Why can't it be added to FloatSize.h? If it can't be added, can't we implement it using the FloatSize::operator*()?

It can be added to FloatSize.h and it would be OK to do that. My change log comment talks about that. I wasn’t sure that adding just this one overload to FloatSize.h was a good idea. I do not think it’s right to implement division by computing the reciprocal and then using multiplication. I don’t think you are guaranteed to get exactly the same result that way as by doing division in the general case. However, it would be fine to convert the LayoutSize to a FloatSize before dividing rather than doing two separate toFloat calls.

>> Source/WebCore/svg/SVGSVGElement.cpp:537
>> +        return root.contentBoxRect().size() / root.style().effectiveZoom();
> 
> Can't we say?
> return root.contentBoxRect().size() * (1 / root.style().effectiveZoom());

We could, but why would we?

>> Source/WebCore/svg/SVGViewElement.cpp:62
>> +    SVGElement::parseAttribute(name, value);
> 
> Is this change to make code clearer? Can't it return bool in case one wants to know if the attribute was parsed by this function or not? Can this change affect the performance?

I think I answered those questions above. We can talk in person about it if you like.
Comment 6 Darin Adler 2015-02-11 21:09:30 PST
Committed r179982: <http://trac.webkit.org/changeset/179982>