[webkit-reviews] review granted: [Bug 78604] Share font-family CSS values through CSSValuePool. : [Attachment 127123] Patch v2
bugzilla-daemon at webkit.org
bugzilla-daemon at webkit.org
Wed Feb 15 09:46:58 PST 2012
Darin Adler <darin at apple.com> has granted Andreas Kling <kling at webkit.org>'s
request for review:
Bug 78604: Share font-family CSS values through CSSValuePool.
https://bugs.webkit.org/show_bug.cgi?id=78604
Attachment 127123: Patch v2
https://bugs.webkit.org/attachment.cgi?id=127123&action=review
------- Additional Comments from Darin Adler <darin at apple.com>
View in context: https://bugs.webkit.org/attachment.cgi?id=127123&action=review
> Source/WebCore/css/CSSParser.cpp:4284
> + { }
Normal style is to put these on successive lines instead of on one line.
> Source/WebCore/css/CSSParser.cpp:4313
> + FontFamilyValueBuilder familyBuilder(list.get(), cssValuePool());
> + bool inFamily = false;
It seems that it would be easy to leave out one call to commit in the code that
follows. I the logic could be slightly clearer if more of the work was done
through builder object and it had a bit more state.
> Source/WebCore/css/CSSValuePool.h:77
> + typedef HashMap<String, RefPtr<FontFamilyValue> > FontFamilyValueCache;
It might be better to use AtomicString for this. We could possibly save some
allocation by going directly from a parser string or a string builder to an
existing AtomicString for an existing family name rather than making a
temporary String that often ends up being used only for map lookup.
Alternatively, we could work on enhancements to HashMap<String, xxx> that could
allow us to look up in the map without allocating a new string. My guess is
that this isn’t so performance-critical that either of those matters, but it is
something I noticed while reviewing.
More information about the webkit-reviews
mailing list