Bug 116783

Summary: Use Vector instead of custom linked list for font families
Product: WebKit Reporter: Antti Koivisto <koivisto>
Component: TextAssignee: Nobody <webkit-unassigned>
Status: RESOLVED FIXED    
Severity: Normal CC: eflews.bot, gyuyoung.kim, kling, rego+ews, webkit-ews, xan.lopez
Priority: P2    
Version: 528+ (Nightly build)   
Hardware: Unspecified   
OS: Unspecified   
Bug Depends on: 116822    
Bug Blocks:    
Attachments:
Description Flags
patch
webkit-ews: commit-queue-
patch 2
eflews.bot: commit-queue-
more port fixes
buildbot: commit-queue-
another kling: review+, buildbot: commit-queue-

Antti Koivisto
Reported 2013-05-26 05:09:14 PDT
And kill a few classes.
Attachments
patch (35.67 KB, patch)
2013-05-26 05:23 PDT, Antti Koivisto
webkit-ews: commit-queue-
patch 2 (38.51 KB, patch)
2013-05-26 06:05 PDT, Antti Koivisto
eflews.bot: commit-queue-
more port fixes (39.99 KB, patch)
2013-05-26 06:44 PDT, Antti Koivisto
buildbot: commit-queue-
another (41.78 KB, patch)
2013-05-26 07:19 PDT, Antti Koivisto
kling: review+
buildbot: commit-queue-
Antti Koivisto
Comment 1 2013-05-26 05:23:27 PDT
Andreas Kling
Comment 2 2013-05-26 05:32:56 PDT
Comment on attachment 202915 [details] patch View in context: https://bugs.webkit.org/attachment.cgi?id=202915&action=review > Source/WebCore/ChangeLog:8 > + No new tests (OOPS!). OOPS! > Source/WebCore/css/CSSComputedStyleDeclaration.cpp:1450 > static PassRefPtr<CSSValueList> fontFamilyFromStyle(RenderStyle* style) > -{ > - const FontFamily& firstFamily = style->fontDescription().family(); > + { Strange indentation here. > Source/WebCore/rendering/RenderText.cpp:211 > - } else if (oldStyle->font().needsTranscoding() != newStyle->font().needsTranscoding() || (newStyle->font().needsTranscoding() && oldStyle->font().family().family() != newStyle->font().family().family())) { > + } else if (oldStyle->font().needsTranscoding() != newStyle->font().needsTranscoding() || (newStyle->font().needsTranscoding() && oldStyle->font().fontDescription().families() != newStyle->font().fontDescription().families())) { You're now comparing all families here instead of just the first one. Looks wrong.
Early Warning System Bot
Comment 3 2013-05-26 05:33:26 PDT
Early Warning System Bot
Comment 4 2013-05-26 05:34:10 PDT
EFL EWS Bot
Comment 5 2013-05-26 05:35:42 PDT
EFL EWS Bot
Comment 6 2013-05-26 05:49:50 PDT
Build Bot
Comment 7 2013-05-26 05:52:25 PDT
Antti Koivisto
Comment 8 2013-05-26 06:05:36 PDT
EFL EWS Bot
Comment 9 2013-05-26 06:23:06 PDT
Comment on attachment 202916 [details] patch 2 Attachment 202916 [details] did not pass efl-wk2-ews (efl-wk2): Output: http://webkit-queues.appspot.com/results/655189
Build Bot
Comment 10 2013-05-26 06:27:10 PDT
EFL EWS Bot
Comment 11 2013-05-26 06:30:50 PDT
Antti Koivisto
Comment 12 2013-05-26 06:44:43 PDT
Created attachment 202918 [details] more port fixes
Build Bot
Comment 13 2013-05-26 07:06:44 PDT
Comment on attachment 202918 [details] more port fixes Attachment 202918 [details] did not pass win-ews (win): Output: http://webkit-queues.appspot.com/results/652347
Antti Koivisto
Comment 14 2013-05-26 07:19:50 PDT
Andreas Kling
Comment 15 2013-05-26 07:21:11 PDT
Comment on attachment 202920 [details] another r=me
Build Bot
Comment 16 2013-05-26 07:46:36 PDT
Antti Koivisto
Comment 17 2013-05-26 07:52:23 PDT
Darin Adler
Comment 18 2013-05-26 17:27:44 PDT
Comment on attachment 202920 [details] another View in context: https://bugs.webkit.org/attachment.cgi?id=202920&action=review > Source/WebCore/platform/graphics/FontDescription.h:144 > + void setOneFamily(const AtomicString& family) { ASSERT(m_families.size() == 1); m_families[0] = family; } I am a little confused by this. How do callers know the families list already happens to be one family long in all the cases where this is used? The name “set one family” also seems a little confusing to me. It sounds like this sets one of the families and leaves the rest alone. I would have maybe called this setSingleFamily. But really I am mystified by the way the code can assume there is only one family. > Source/WebCore/platform/graphics/FontDescription.h:173 > - FontFamily m_familyList; // The list of font families to be used. > + Vector<AtomicString, 1> m_families; The old thing was two pointers. Isn’t Vector<AtomicString, 1> much bigger than that?
Antti Koivisto
Comment 19 2013-05-26 17:53:26 PDT
(In reply to comment #18) > (From update of attachment 202920 [details]) > View in context: https://bugs.webkit.org/attachment.cgi?id=202920&action=review > > > Source/WebCore/platform/graphics/FontDescription.h:144 > > + void setOneFamily(const AtomicString& family) { ASSERT(m_families.size() == 1); m_families[0] = family; } > > I am a little confused by this. How do callers know the families list already happens to be one family long in all the cases where this is used? FontDescription is not meant to be mutated after the initial setup. The size is set to one in constructor to match the old behaviour and limit the refactoring. This could actually assert that the family is null too. > The name “set one family” also seems a little confusing to me. It sounds like this sets one of the families and leaves the rest alone. I would have maybe called this setSingleFamily. But really I am mystified by the way the code can assume there is only one family. Yeah, setSingleFamily would be a better name. Removing the whole thing in favour of constructor parameter would be better. > The old thing was two pointers. Isn’t Vector<AtomicString, 1> much bigger than that? This is not meant to be the end state. A simplification step will hopefully be helpful to get bigger gains.
Andreas Kling
Comment 20 2013-05-26 17:54:58 PDT
(In reply to comment #19) > (In reply to comment #18) > > (From update of attachment 202920 [details] [details]) > > View in context: https://bugs.webkit.org/attachment.cgi?id=202920&action=review > > The old thing was two pointers. Isn’t Vector<AtomicString, 1> much bigger than that? > > This is not meant to be the end state. A simplification step will hopefully be helpful to get bigger gains. FWIW, the new object is one pointer bigger, but has much better heap layout with >1 family.
Note You need to log in before you can comment on or make changes to this bug.