Bug 116783 - Use Vector instead of custom linked list for font families
Summary: Use Vector instead of custom linked list for font families
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: Text (show other bugs)
Version: 528+ (Nightly build)
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Nobody
URL:
Keywords:
Depends on: 116822
Blocks:
  Show dependency treegraph
 
Reported: 2013-05-26 05:09 PDT by Antti Koivisto
Modified: 2013-05-27 04:46 PDT (History)
6 users (show)

See Also:


Attachments
patch (35.67 KB, patch)
2013-05-26 05:23 PDT, Antti Koivisto
webkit-ews: commit-queue-
Details | Formatted Diff | Diff
patch 2 (38.51 KB, patch)
2013-05-26 06:05 PDT, Antti Koivisto
eflews.bot: commit-queue-
Details | Formatted Diff | Diff
more port fixes (39.99 KB, patch)
2013-05-26 06:44 PDT, Antti Koivisto
buildbot: commit-queue-
Details | Formatted Diff | Diff
another (41.78 KB, patch)
2013-05-26 07:19 PDT, Antti Koivisto
kling: review+
buildbot: commit-queue-
Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Antti Koivisto 2013-05-26 05:09:14 PDT
And kill a few classes.
Comment 1 Antti Koivisto 2013-05-26 05:23:27 PDT
Created attachment 202915 [details]
patch
Comment 2 Andreas Kling 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.
Comment 3 Early Warning System Bot 2013-05-26 05:33:26 PDT
Comment on attachment 202915 [details]
patch

Attachment 202915 [details] did not pass qt-ews (qt):
Output: http://webkit-queues.appspot.com/results/677274
Comment 4 Early Warning System Bot 2013-05-26 05:34:10 PDT
Comment on attachment 202915 [details]
patch

Attachment 202915 [details] did not pass qt-wk2-ews (qt-wk2):
Output: http://webkit-queues.appspot.com/results/677273
Comment 5 EFL EWS Bot 2013-05-26 05:35:42 PDT
Comment on attachment 202915 [details]
patch

Attachment 202915 [details] did not pass efl-wk2-ews (efl-wk2):
Output: http://webkit-queues.appspot.com/results/665163
Comment 6 EFL EWS Bot 2013-05-26 05:49:50 PDT
Comment on attachment 202915 [details]
patch

Attachment 202915 [details] did not pass efl-ews (efl):
Output: http://webkit-queues.appspot.com/results/744168
Comment 7 Build Bot 2013-05-26 05:52:25 PDT
Comment on attachment 202915 [details]
patch

Attachment 202915 [details] did not pass win-ews (win):
Output: http://webkit-queues.appspot.com/results/744167
Comment 8 Antti Koivisto 2013-05-26 06:05:36 PDT
Created attachment 202916 [details]
patch 2
Comment 9 EFL EWS Bot 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
Comment 10 Build Bot 2013-05-26 06:27:10 PDT
Comment on attachment 202916 [details]
patch 2

Attachment 202916 [details] did not pass win-ews (win):
Output: http://webkit-queues.appspot.com/results/744171
Comment 11 EFL EWS Bot 2013-05-26 06:30:50 PDT
Comment on attachment 202916 [details]
patch 2

Attachment 202916 [details] did not pass efl-ews (efl):
Output: http://webkit-queues.appspot.com/results/730153
Comment 12 Antti Koivisto 2013-05-26 06:44:43 PDT
Created attachment 202918 [details]
more port fixes
Comment 13 Build Bot 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
Comment 14 Antti Koivisto 2013-05-26 07:19:50 PDT
Created attachment 202920 [details]
another
Comment 15 Andreas Kling 2013-05-26 07:21:11 PDT
Comment on attachment 202920 [details]
another

r=me
Comment 16 Build Bot 2013-05-26 07:46:36 PDT
Comment on attachment 202920 [details]
another

Attachment 202920 [details] did not pass win-ews (win):
Output: http://webkit-queues.appspot.com/results/744186
Comment 17 Antti Koivisto 2013-05-26 07:52:23 PDT
http://trac.webkit.org/changeset/150716
Comment 18 Darin Adler 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?
Comment 19 Antti Koivisto 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.
Comment 20 Andreas Kling 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.