Summary: | Move parsing of the form attribute attribute to MathMLOperatorElement | ||||||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Product: | WebKit | Reporter: | Frédéric Wang (:fredw) <fred.wang> | ||||||||||||||||||||||||||||||||||||||
Component: | MathML | Assignee: | Frédéric Wang (:fredw) <fred.wang> | ||||||||||||||||||||||||||||||||||||||
Status: | RESOLVED FIXED | ||||||||||||||||||||||||||||||||||||||||
Severity: | Normal | CC: | alex, bfulgham, buildbot, commit-queue, darin, dbarton, esprehn+autocc, glenn, kondapallykalyan, rego, rniwa | ||||||||||||||||||||||||||||||||||||||
Priority: | P2 | ||||||||||||||||||||||||||||||||||||||||
Version: | WebKit Nightly Build | ||||||||||||||||||||||||||||||||||||||||
Hardware: | Unspecified | ||||||||||||||||||||||||||||||||||||||||
OS: | Unspecified | ||||||||||||||||||||||||||||||||||||||||
Bug Depends on: | 160034, 160241 | ||||||||||||||||||||||||||||||||||||||||
Bug Blocks: | 156537, 160190 | ||||||||||||||||||||||||||||||||||||||||
Attachments: |
|
Description
Frédéric Wang (:fredw)
2016-07-27 04:47:00 PDT
Created attachment 284762 [details]
Patch (applies after bugs 160241 and 160245)
Created attachment 284782 [details]
Patch (applies after bugs 160241 and 160245)
Just some minor renaming as the leading/trailing functions are really for the default spacing not the one specified in the attributes.
Comment on attachment 284782 [details] Patch (applies after bugs 160241 and 160245) View in context: https://bugs.webkit.org/attachment.cgi?id=284782&action=review > Source/WebCore/ChangeLog:3 > + Move parsing of the form attribute attribute to MathMLOperatorElement nit: duplicated "attribute" term. > Source/WebCore/mathml/MathMLOperatorDictionary.cpp:1117 > + if (const Entry* entry = getEntry(character, static_cast<Form>(form))) Use 'auto' here since the type¡ is well known. Also, why "const" ? I don't get why we need the static_cast<Form>, since the form argument is already of such type. > Source/WebCore/mathml/MathMLOperatorDictionary.cpp:1124 > + if (const Entry* entry = getEntry(character)) Use 'auto' here. I think the code will be simpler if getEntry return an Optional<Entry> > Source/WebCore/mathml/MathMLOperatorElement.cpp:76 > + const AtomicString& value = attributeWithoutSynchronization(formAttr); We can use just "auto& value" here. > Source/WebCore/mathml/MathMLOperatorElement.cpp:125 > + return space; we could do it simpler return { LengthType::MathUnit, (float)dictionaryProperty().leadingSpaceInMathUnit }; > Source/WebCore/mathml/MathMLOperatorElement.cpp:133 > + return space; Ditto. > Source/WebCore/mathml/MathMLOperatorElement.cpp:146 > + m_dictionaryProperty.dirty = true; I'm not sure if it may happen, but I assume m_dictionaryProperty.dirty could be already dirty, so this line does nothing useful. Do you think it'd be better to do this instead ? m_dictionaryProperty.dirty |= name == formAttr; > Source/WebCore/rendering/mathml/RenderMathMLFencedOperator.cpp:-29 > - Do we need to remove this line ? > Source/WebCore/rendering/mathml/RenderMathMLFencedOperator.cpp:59 > + m_leadingSpace = 5 * style().fontCascade().size() / 18; // This sets leading space to "thickmathspace". Perhaps it'd be a good idea to use named constants for these values. > Source/WebCore/rendering/mathml/RenderMathMLFencedOperator.cpp:60 > + m_trailingSpace = 5 * style().fontCascade().size() / 18; // This sets trailing space to "thickmathspace". ditto. > Source/WebCore/rendering/mathml/RenderMathMLFencedOperator.cpp:62 > + m_maxSize = intMaxForLayoutUnit; // This sets maxsize to "infinity". It seems m_maxSize is always intMaxForLayoutUnit. Perhaps we could just define it as a static constant and initialize it in the class. > Source/WebCore/rendering/mathml/RenderMathMLFencedOperator.cpp:66 > + m_leadingSpace = entry.value().lspace * style().fontCascade().size() / 18; It looks like style().fontCascade().size() / 18 is a value we use several times in this class. Perhaps we can cached it somewhere and avoid repeating the same arithmetic operation. > Source/WebCore/rendering/mathml/RenderMathMLFencedOperator.cpp:67 > + m_trailingSpace = entry.value().rspace * style().fontCascade().size() / 18; Ditto. Created attachment 284992 [details]
Patch
Created attachment 284993 [details]
Patch
(In reply to comment #3) > nit: duplicated "attribute" term. Fixed. > > Source/WebCore/mathml/MathMLOperatorDictionary.cpp:1117 > > + if (const Entry* entry = getEntry(character, static_cast<Form>(form))) > > Use 'auto' here since the type¡ is well known. > Also, why "const" ? > I don't get why we need the static_cast<Form>, since the form argument is > already of such type. > > > Source/WebCore/mathml/MathMLOperatorDictionary.cpp:1124 > > + if (const Entry* entry = getEntry(character)) > > Use 'auto' here. > > I think the code will be simpler if getEntry return an Optional<Entry> There are some constraints due to using the tryBinarySearch on the const dictionary array. I've tried simplifying this code in the new patch. > We can use just "auto& value" here. Done. > we could do it simpler > > return { LengthType::MathUnit, > (float)dictionaryProperty().leadingSpaceInMathUnit }; Done > > Source/WebCore/mathml/MathMLOperatorElement.cpp:146 > > + m_dictionaryProperty.dirty = true; > > I'm not sure if it may happen, but I assume m_dictionaryProperty.dirty could > be already dirty, so this line does nothing useful. > Do you think it'd be better to do this instead ? > > m_dictionaryProperty.dirty |= name == formAttr; Yes, it happens each time one modifies the form attribute two or more times. This is a point of having the dirty boolean to avoid calling parsing each time the attribute changes. I'm not sure such optimization is worth doing, probably the compilers will be clever enough to handle them. Moreover, this code will have several "if else" in follow-up patches so I'm not sure this will be possible / readable. > > > Source/WebCore/rendering/mathml/RenderMathMLFencedOperator.cpp:-29 > > - > > Do we need to remove this line ? I thought the check-webkit-style complained about it but apparently not. > > > Source/WebCore/rendering/mathml/RenderMathMLFencedOperator.cpp:59 > > + m_leadingSpace = 5 * style().fontCascade().size() / 18; // This sets leading space to "thickmathspace". > > Perhaps it'd be a good idea to use named constants for these values. OK, I've use toUserUnits and a gThickMathSpace constant. > > Source/WebCore/rendering/mathml/RenderMathMLFencedOperator.cpp:62 > > + m_maxSize = intMaxForLayoutUnit; // This sets maxsize to "infinity". > > It seems m_maxSize is always intMaxForLayoutUnit. Perhaps we could just > define it as a static constant and initialize it in the class. I've init it in the constructor. For this and minsize I'm not sure it's worth doing too much thing at this point. It will be much easier to simplify after the refactoring of the length attributes (see bug 160301 and bug 160336). > > > Source/WebCore/rendering/mathml/RenderMathMLFencedOperator.cpp:66 > > + m_leadingSpace = entry.value().lspace * style().fontCascade().size() / 18; > > It looks like style().fontCascade().size() / 18 is a value we use several > times in this class. Perhaps we can cached it somewhere and avoid repeating > the same arithmetic operation. OK, I've used toUserUnits here too. Created attachment 284994 [details]
Patch
Created attachment 284995 [details]
Patch
(In reply to comment #3) > > Source/WebCore/mathml/MathMLOperatorElement.cpp:125 > > + return space; > > we could do it simpler > > return { LengthType::MathUnit, > (float)dictionaryProperty().leadingSpaceInMathUnit }; > For some reason, the GTK bot complained about the missing dirty member so I had to make it explicit. Comment on attachment 284995 [details] Patch Attachment 284995 [details] did not pass mac-ews (mac): Output: http://webkit-queues.webkit.org/results/1790126 New failing tests: mathml/presentation/fenced.html mathml/presentation/fenced-mi.html Created attachment 284996 [details]
Archive of layout-test-results from ews103 for mac-yosemite
The attached test failures were seen while running run-webkit-tests on the mac-ews.
Bot: ews103 Port: mac-yosemite Platform: Mac OS X 10.10.5
Comment on attachment 284995 [details] Patch Attachment 284995 [details] did not pass mac-wk2-ews (mac-wk2): Output: http://webkit-queues.webkit.org/results/1790176 New failing tests: mathml/presentation/fenced.html mathml/presentation/fenced-mi.html Created attachment 284998 [details]
Archive of layout-test-results from ews105 for mac-yosemite-wk2
The attached test failures were seen while running run-webkit-tests on the mac-wk2-ews.
Bot: ews105 Port: mac-yosemite-wk2 Platform: Mac OS X 10.10.5
Comment on attachment 284995 [details] Patch Attachment 284995 [details] did not pass ios-sim-ews (ios-simulator-wk2): Output: http://webkit-queues.webkit.org/results/1790177 New failing tests: mathml/presentation/fenced.html mathml/presentation/fenced-mi.html Created attachment 284999 [details]
Archive of layout-test-results from ews123 for ios-simulator-wk2
The attached test failures were seen while running run-webkit-tests on the ios-sim-ews.
Bot: ews123 Port: ios-simulator-wk2 Platform: Mac OS X 10.11.5
Comment on attachment 284995 [details] Patch Attachment 284995 [details] did not pass mac-debug-ews (mac): Output: http://webkit-queues.webkit.org/results/1790359 New failing tests: mathml/presentation/fenced.html mathml/presentation/fenced-mi.html Created attachment 285002 [details]
Archive of layout-test-results from ews112 for mac-yosemite
The attached test failures were seen while running run-webkit-tests on the mac-debug-ews.
Bot: ews112 Port: mac-yosemite Platform: Mac OS X 10.10.5
Created attachment 285003 [details]
Patch
Created attachment 285004 [details]
Patch
Created attachment 285011 [details]
Patch
(In reply to comment #9) > (In reply to comment #3) > > > Source/WebCore/mathml/MathMLOperatorElement.cpp:125 > > > + return space; > > > > we could do it simpler > > > > return { LengthType::MathUnit, > > (float)dictionaryProperty().leadingSpaceInMathUnit }; > > > > For some reason, the GTK bot complained about the missing dirty member so I > had to make it explicit. It seems that GTK bot has random build errors with that syntax and the Win one is not happy either, so for now I'll keep the more verbose syntax. Comment on attachment 285011 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=285011&action=review > Source/WebCore/mathml/MathMLOperatorDictionary.cpp:1095 > + return Optional<Entry>(); Should use Nullopt or { }. > Source/WebCore/mathml/MathMLOperatorDictionary.cpp:1099 > + return Optional<Entry>(*entry); Should not need a typecast at all here. > Source/WebCore/mathml/MathMLOperatorDictionary.cpp:1102 > + return Optional<Entry>(); Should use Nullopt or { }. > Source/WebCore/mathml/MathMLOperatorDictionary.cpp:1112 > + return Optional<Entry>(*entry); Should not need a typecast here. > Source/WebCore/mathml/MathMLOperatorDictionary.cpp:1115 > + return Optional<Entry>(); Should use Nullopt or { }. > Source/WebCore/mathml/MathMLOperatorElement.cpp:71 > +const MathMLOperatorElement::DictionaryProperty& MathMLOperatorElement::dictionaryProperty() I think it might be slightly better to factor the part that computes the value from an attribute into a separate function. I’d like this: If (!m_dictionaryProperty) m_dictionaryProperty = computeDictionaryProperty(); return m_dictionaryProperty.value(); > Source/WebCore/mathml/MathMLOperatorElement.cpp:79 > + m_dictionaryProperty.value().form = Prefix; Does this work if m_dictionaryProperty is null? I guess it constructs a default empty value and then assigns form. > Source/WebCore/mathml/MathMLOperatorElement.cpp:95 > + if (Optional<Entry> entry = search(operatorText(), m_dictionaryProperty.value().form, explicitForm)) { I’d suggest using auto here instead of Optional<Entry>. > Source/WebCore/mathml/MathMLOperatorElement.cpp:138 > m_operatorText = Optional<UChar>(); > + m_dictionaryProperty = Optional<DictionaryProperty>(); More Nullopt would be better, I think. Comment on attachment 285011 [details] Patch Attachment 285011 [details] did not pass mac-debug-ews (mac): Output: http://webkit-queues.webkit.org/results/1792991 Number of test failures exceeded the failure limit. Created attachment 285021 [details]
Archive of layout-test-results from ews117 for mac-yosemite
The attached test failures were seen while running run-webkit-tests on the mac-debug-ews.
Bot: ews117 Port: mac-yosemite Platform: Mac OS X 10.10.5
Created attachment 285090 [details]
Patch
Created attachment 285093 [details]
Patch
Created attachment 285095 [details]
Patch
Committed r204022: <http://trac.webkit.org/changeset/204022> |