WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED FIXED
69838
Resolve regular and visited link style in a single pass
https://bugs.webkit.org/show_bug.cgi?id=69838
Summary
Resolve regular and visited link style in a single pass
Antti Koivisto
Reported
2011-10-11 07:12:32 PDT
We can simplify and speed up selector matching by removing the recursive matching done to generate the style for :visited pseudo selector. Both regular and visited link style can be generated in a single pass though the style selector. Recursive visited style mathing is ~20% of the total time spent under styleForElement.
Attachments
patch
(46.34 KB, patch)
2011-10-11 11:24 PDT
,
Antti Koivisto
darin
: review+
Details
Formatted Diff
Diff
View All
Add attachment
proposed patch, testcase, etc.
Antti Koivisto
Comment 1
2011-10-11 11:24:21 PDT
Created
attachment 110545
[details]
patch The next step would be to get rid of the separate RenderStyle object for the visited style alltogether. The few fields used can be part of the regular RenderStyle.
Darin Adler
Comment 2
2011-10-11 17:33:47 PDT
Comment on
attachment 110545
[details]
patch View in context:
https://bugs.webkit.org/attachment.cgi?id=110545&action=review
I read over this and did not spot any mistakes.
> Source/WebCore/css/CSSStyleSelector.cpp:210 > - unsigned m_position : 28; > + unsigned m_position : 26;
How many bits do we really need for this? Can it be even less than 26? How do we handle overflow?
> Source/WebCore/css/CSSStyleSelector.cpp:1292 > + // pseudo element styles will continue to work for pseudo elements inside :visited > + // links.
I’d put that last word on the previous line.
> Source/WebCore/css/SelectorChecker.h:90 > + enum LinkMatchMask { MatchLink = 1, MatchVisited = 2, MatchAll = MatchLink | MatchVisited };
Extra space here before MatchLink.
> Source/WebCore/rendering/style/RenderStyle.cpp:260 > + ASSERT(pseudo->styleType() > NOPSEUDO);
Might be worth a “why this is a good assertion” comment.
Antti Koivisto
Comment 3
2011-10-12 00:50:02 PDT
(In reply to
comment #2
)
> (From update of
attachment 110545
[details]
) > View in context:
https://bugs.webkit.org/attachment.cgi?id=110545&action=review
> > I read over this and did not spot any mistakes. > > > Source/WebCore/css/CSSStyleSelector.cpp:210 > > - unsigned m_position : 28; > > + unsigned m_position : 26; > > How many bits do we really need for this? Can it be even less than 26? How do we handle overflow?
We need enough bits to hold the total count of all (author) style rules that may apply to a document. In practice we can do with way less bits than this still. Overflow is not handled. It is not particularly dangerous (just messes up the style resolution) and we are going to be in trouble with millions of rules well before that anyway.
Antti Koivisto
Comment 4
2011-10-12 02:20:20 PDT
http://trac.webkit.org/changeset/97248
Balazs Kelemen
Comment 5
2011-10-12 08:46:02 PDT
Our Qt-Debug-32bit bot has a css related assertion fail and I find this patch as the most likely reason. Could you take a look to the crash log in #69933? Thanks.
Ryosuke Niwa
Comment 6
2011-10-12 21:51:50 PDT
svg/hixie/cascade/002.xml started failing on GTK after this patch:
http://test-results.appspot.com/dashboards/flakiness_dashboard.html#group=%40ToT%20-%20webkit.org&tests=svg%2Fhixie%2Fcascade%2F002.xml
Antti Koivisto
Comment 7
2011-10-14 11:36:39 PDT
(In reply to
comment #6
)
> svg/hixie/cascade/002.xml started failing on GTK after this patch: >
http://test-results.appspot.com/dashboards/flakiness_dashboard.html#group=%40ToT%20-%20webkit.org&tests=svg%2Fhixie%2Fcascade%2F002.xml
Filed
https://bugs.webkit.org/show_bug.cgi?id=70122
for this. Seems like our visited link test coverage is actually really bad as drt doesn't support them properly.
Ryosuke Niwa
Comment 8
2011-10-14 11:50:08 PDT
(In reply to
comment #7
)
> (In reply to
comment #6
) > > svg/hixie/cascade/002.xml started failing on GTK after this patch: > >
http://test-results.appspot.com/dashboards/flakiness_dashboard.html#group=%40ToT%20-%20webkit.org&tests=svg%2Fhixie%2Fcascade%2F002.xml
> > Filed
https://bugs.webkit.org/show_bug.cgi?id=70122
for this. Seems like our visited link test coverage is actually really bad as drt doesn't support them properly.
Thanks! Is it possible to add some internals method to improve the test coverage?
Antti Koivisto
Comment 9
2011-10-14 12:45:59 PDT
(In reply to
comment #8
)
> Thanks! Is it possible to add some internals method to improve the test coverage?
It just requires some simple fixes to make <a href=""> work correctly in DRT. That is always considered visited so it can be used for testing. Some tests use it already but end up with incorrect DRT results due to some easy bugs.
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug