Bug 107080 - Remove a TextTrack.h include from the Element.h and move WebVTT related stuff outside the Element
Summary: Remove a TextTrack.h include from the Element.h and move WebVTT related stuff...
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: Media (show other bugs)
Version: 528+ (Nightly build)
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Dima Gorbik
URL:
Keywords: InRadar
Depends on:
Blocks:
 
Reported: 2013-01-16 18:29 PST by Dima Gorbik
Modified: 2013-01-18 20:01 PST (History)
14 users (show)

See Also:


Attachments
Proposed fix 0.1 (21.69 KB, patch)
2013-01-17 18:52 PST, Dima Gorbik
buildbot: commit-queue-
Details | Formatted Diff | Diff
Proposed fix 0.2 (21.08 KB, patch)
2013-01-18 18:34 PST, Dima Gorbik
sam: review+
Details | Formatted Diff | Diff
Proposed fix 0.3 (21.15 KB, patch)
2013-01-18 19:11 PST, Dima Gorbik
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Dima Gorbik 2013-01-16 18:29:05 PST
We should try to keep hot include files light in terms of sub includes to reduce build times.
Comment 1 Dima Gorbik 2013-01-17 18:52:17 PST
Created attachment 183349 [details]
Proposed fix 0.1
Comment 2 Elliott Sprehn 2013-01-17 19:01:08 PST
Comment on attachment 183349 [details]
Proposed fix 0.1

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

> Source/WebCore/css/SelectorChecker.cpp:948
> +            return (element->isWebVTTElement() && toWebVTTElement(element)->webVTTNodeType() == WebVTTNodeTypeFuture);

Instead of this incantation in multiple places it would be nicer to hide this in a method on Element, Element::webVTTNodeType() const { return isWebVTTElement(this) ? toWebVTTElement(this)->type() ? WebVTTNodeTypeNone; };

There's no reason for the method on WebVTTElement to be called webVTTNodeType, it should just be called type() or something.

> Source/WebCore/html/track/WebVTTElement.h:32
> +enum WebVTTNodeType {

WebVTTElementType ? And also fix the setters and such to be setWebVTTType() I don't really see a reason to repeat Node and Element so many times.

> Source/WebCore/html/track/WebVTTElement.h:58
> +    ASSERT(tagName.localName().impl());

This is a really weird assert to make. Shouldn't Element already assert about this?
Comment 3 Dima Gorbik 2013-01-17 19:05:27 PST
(In reply to comment #2)
> (From update of attachment 183349 [details])
> View in context: https://bugs.webkit.org/attachment.cgi?id=183349&action=review
> 
> > Source/WebCore/css/SelectorChecker.cpp:948
> > +            return (element->isWebVTTElement() && toWebVTTElement(element)->webVTTNodeType() == WebVTTNodeTypeFuture);
> 
> Instead of this incantation in multiple places it would be nicer to hide this in a method on Element, Element::webVTTNodeType() const { return isWebVTTElement(this) ? toWebVTTElement(this)->type() ? WebVTTNodeTypeNone; };

I will end up with an include in Element.h again, what's the purpose of the patch then?
Comment 4 Build Bot 2013-01-17 21:18:29 PST
Comment on attachment 183349 [details]
Proposed fix 0.1

Attachment 183349 [details] did not pass win-ews (win):
Output: http://queues.webkit.org/results/15947246
Comment 5 Elliott Sprehn 2013-01-18 09:58:03 PST
(In reply to comment #3)
> (In reply to comment #2)
> > (From update of attachment 183349 [details] [details])
> > View in context: https://bugs.webkit.org/attachment.cgi?id=183349&action=review
> > 
> > > Source/WebCore/css/SelectorChecker.cpp:948
> > > +            return (element->isWebVTTElement() && toWebVTTElement(element)->webVTTNodeType() == WebVTTNodeTypeFuture);
> > 
> > Instead of this incantation in multiple places it would be nicer to hide this in a method on Element, Element::webVTTNodeType() const { return isWebVTTElement(this) ? toWebVTTElement(this)->type() ? WebVTTNodeTypeNone; };
> 
> I will end up with an include in Element.h again, what's the purpose of the patch then?

Not if you make it non-inline, or if you place the inline version in the WebVTTElement.h, it's not that big a deal. :)

It does occur to me that you're putting multiple virtual method calls in the middle of selector matching which is rather hot, you'll want to cache that value like we do for isFormControlElement() in that method.
Comment 6 Elliott Sprehn 2013-01-18 15:23:24 PST
(In reply to comment #5)
> ...
> Not if you make it non-inline, or if you place the inline version in the WebVTTElement.h, it's not that big a deal. :)
> 

Discussed this on IRC, I think we should just leave the patch the way it is in terms of the methods. Ignore my suggestion in this bug.
Comment 7 Dima Gorbik 2013-01-18 18:34:33 PST
Created attachment 183590 [details]
Proposed fix 0.2
Comment 8 Dima Gorbik 2013-01-18 18:37:49 PST
(In reply to comment #5)
> It does occur to me that you're putting multiple virtual method calls in the middle of selector matching which is rather hot, you'll want to cache that value like we do for isFormControlElement() in that method.

This code is located in the function that checks if we may share styles. It's not being called too often, so probably we don't have to do that kind of caching.
Comment 9 Sam Weinig 2013-01-18 18:45:43 PST
Comment on attachment 183590 [details]
Proposed fix 0.2

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

> Source/WebCore/html/track/WebVTTElement.h:32
> +enum WebVTTNodeType {

This should probably be WebVTTElementType, no?

> Source/WebCore/html/track/WebVTTElement.h:48
> +    WebVTTElement(const QualifiedName& tagName, Document*);

No need for tagName here.  This should probably be private.

> Source/WebCore/html/track/WebVTTElement.h:56
> +: HTMLElement(tagName, document)
> +, m_webVTTNodeType(WebVTTNodeTypeNone)

These should be indented.  Does this need to be in the header?

> Source/WebCore/html/track/WebVTTElement.h:60
> +inline WebVTTElement* toWebVTTElement(Node* node)

You should probably also add a 

// This will catch anyone doing an unnecessary cast.
void toWebVTTElement(const WebVTTElement*); 

without an implementation.
Comment 10 Dima Gorbik 2013-01-18 19:11:09 PST
Created attachment 183593 [details]
Proposed fix 0.3
Comment 11 Radar WebKit Bug Importer 2013-01-18 19:13:12 PST
<rdar://problem/13047516>
Comment 12 WebKit Review Bot 2013-01-18 20:01:17 PST
Comment on attachment 183593 [details]
Proposed fix 0.3

Clearing flags on attachment: 183593

Committed r140231: <http://trac.webkit.org/changeset/140231>
Comment 13 WebKit Review Bot 2013-01-18 20:01:23 PST
All reviewed patches have been landed.  Closing bug.