RESOLVED FIXED 98244
[Refactoring] Scoped Style related code should have its own class.
https://bugs.webkit.org/show_bug.cgi?id=98244
Summary [Refactoring] Scoped Style related code should have its own class.
Hajime Morrita
Reported 2012-10-03 02:25:10 PDT
This is preparation for Bug 95664. By extracting scoped stylesheet feature to separate code path, we could see how it affects the performance for both scoped and non-scoped style cases. It would clarify the impact of making scoping machinery available for Shadow DOM.
Attachments
WIP (81.49 KB, patch)
2012-10-03 02:35 PDT, Hajime Morrita
no flags
WIP (84.33 KB, patch)
2012-10-03 03:45 PDT, Hajime Morrita
no flags
Patch (97.67 KB, patch)
2012-10-04 02:10 PDT, Hajime Morrita
no flags
Patch (26.69 KB, patch)
2012-10-05 02:49 PDT, Hajime Morrita
no flags
I'm back (34.13 KB, patch)
2012-10-05 03:21 PDT, Hajime Morrita
no flags
Patch for landing (34.18 KB, patch)
2012-10-08 18:41 PDT, Hajime Morrita
no flags
Patch for landing (34.19 KB, patch)
2012-10-08 20:54 PDT, Hajime Morrita
no flags
Hajime Morrita
Comment 1 2012-10-03 02:35:36 PDT
Hajime Morrita
Comment 2 2012-10-03 03:45:37 PDT
Early Warning System Bot
Comment 3 2012-10-03 03:57:51 PDT
Build Bot
Comment 4 2012-10-03 04:00:29 PDT
Build Bot
Comment 5 2012-10-03 04:12:57 PDT
Early Warning System Bot
Comment 6 2012-10-03 04:15:53 PDT
Gyuyoung Kim
Comment 7 2012-10-03 04:17:04 PDT
Dimitri Glazkov (Google)
Comment 8 2012-10-03 09:28:41 PDT
This is interesting. Are you planning to break this up into several patches to land?
Hajime Morrita
Comment 9 2012-10-04 02:10:23 PDT
Build Bot
Comment 10 2012-10-04 02:15:44 PDT
Early Warning System Bot
Comment 11 2012-10-04 02:22:20 PDT
Early Warning System Bot
Comment 12 2012-10-04 02:23:52 PDT
Build Bot
Comment 13 2012-10-04 02:41:15 PDT
Dimitri Glazkov (Google)
Comment 14 2012-10-04 10:35:51 PDT
Comment on attachment 167057 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=167057&action=review I really like splitting out scope-related things into its own class, and anything else that makes StyleResolver a smaller seems like a win. Having said that, the patch is too large and needs to be split up to allow for meaningful review. Maybe we could start with moving RuleData/RuleSet into their own files? Also, is there a performance impact? > Source/WebCore/css/StyleResolver.cpp:401 > +bool StyleResolver::usesSiblingRules() const > +{ > + return !m_features->siblingRules.isEmpty(); > +} > + > +bool StyleResolver::usesFirstLineRules() const > +{ > + return m_features->usesFirstLineRules; > +} > + > +bool StyleResolver::usesBeforeAfterRules() const > +{ > + return m_features->usesBeforeAfterRules; > +} Probably should go at the bottom of StyleResolver.h with inline prefix? Or has this convention changed? > Source/WebCore/css/StyleResolverRules.h:26 > +#ifndef StyleResolverRules_h Can we name it to match at least one class name in the header? This way, it will be easier to find by file name. How about RuleSet, since it's the majority of the code?
Hajime Morrita
Comment 15 2012-10-04 17:34:18 PDT
Dimitri, thanks for your feedback. I'll create sub-bug to split existing class out from StyleResolver.cpp/h
Hajime Morrita
Comment 16 2012-10-04 17:36:12 PDT
(In reply to comment #14) > (From update of attachment 167057 [details]) > View in context: https://bugs.webkit.org/attachment.cgi?id=167057&action=review > > I really like splitting out scope-related things into its own class, and anything else that makes StyleResolver a smaller seems like a win. > > > Having said that, the patch is too large and needs to be split up to allow for meaningful review. Maybe we could start with moving RuleData/RuleSet into their own files? > > Also, is there a performance impact? > > > Source/WebCore/css/StyleResolver.cpp:401 > > +bool StyleResolver::usesSiblingRules() const > > +{ > > + return !m_features->siblingRules.isEmpty(); > > +} > > + > > +bool StyleResolver::usesFirstLineRules() const > > +{ > > + return m_features->usesFirstLineRules; > > +} > > + > > +bool StyleResolver::usesBeforeAfterRules() const > > +{ > > + return m_features->usesBeforeAfterRules; > > +} > > Probably should go at the bottom of StyleResolver.h with inline prefix? Or has this convention changed? > It looks I went too far here. Will keep existing code and just fucus renaming for now.
Hajime Morrita
Comment 17 2012-10-05 02:49:52 PDT
Build Bot
Comment 18 2012-10-05 02:55:55 PDT
Gyuyoung Kim
Comment 19 2012-10-05 03:09:08 PDT
Hajime Morrita
Comment 20 2012-10-05 03:21:56 PDT
Created attachment 167296 [details] I'm back
Build Bot
Comment 21 2012-10-05 03:31:11 PDT
Early Warning System Bot
Comment 22 2012-10-05 03:51:03 PDT
Early Warning System Bot
Comment 23 2012-10-05 04:23:54 PDT
Comment on attachment 167296 [details] I'm back Attachment 167296 [details] did not pass qt-wk2-ews (qt): Output: http://queues.webkit.org/results/14180417
Build Bot
Comment 24 2012-10-05 05:19:17 PDT
Dimitri Glazkov (Google)
Comment 25 2012-10-05 09:09:49 PDT
Comment on attachment 167296 [details] I'm back View in context: https://bugs.webkit.org/attachment.cgi?id=167296&action=review This is great. Please make the bubbles happy before landing. > Source/WebCore/css/StyleResolver.h:489 > + OwnPtr<StyleScopeResolver> m_scoper; Who u callin scoper? http://www.urbandictionary.com/define.php?term=Scoper Maybe m_scopeResolver would be better :)
Hajime Morrita
Comment 26 2012-10-08 18:06:42 PDT
(In reply to comment #25) > (From update of attachment 167296 [details]) > View in context: https://bugs.webkit.org/attachment.cgi?id=167296&action=review > > This is great. Please make the bubbles happy before landing. > > > Source/WebCore/css/StyleResolver.h:489 > > + OwnPtr<StyleScopeResolver> m_scoper; > > Who u callin scoper? http://www.urbandictionary.com/define.php?term=Scoper > > Maybe m_scopeResolver would be better :) Right. I was grabbed by the short-name-tempation... Thanks for your review Dimitri, I'll fix it and the build breaks then land this.
Hajime Morrita
Comment 27 2012-10-08 18:41:00 PDT
Created attachment 167667 [details] Patch for landing
Hajime Morrita
Comment 28 2012-10-08 18:42:45 PDT
Comment on attachment 167667 [details] Patch for landing cq- for now to see EWS result.
WebKit Review Bot
Comment 29 2012-10-08 20:01:09 PDT
Comment on attachment 167667 [details] Patch for landing Rejecting attachment 167667 [details] from commit-queue. Failed to run "['/mnt/git/webkit-commit-queue/Tools/Scripts/webkit-patch', '--status-host=queues.webkit.org', '-..." exit_code: 2 Last 500 characters of output: Kit/chromium/third_party/yasm/source/patched-yasm --revision 154708 --non-interactive --force --accept theirs-conflict --ignore-externals' in '/mnt/git/webkit-commit-queue/Source/WebKit/chromium' 51>At revision 154708. ________ running '/usr/bin/python tools/clang/scripts/update.py --mac-only' in '/mnt/git/webkit-commit-queue/Source/WebKit/chromium' ________ running '/usr/bin/python gyp_webkit' in '/mnt/git/webkit-commit-queue/Source/WebKit/chromium' Updating webkit projects from gyp files... Full output: http://queues.webkit.org/results/14221508
Hajime Morrita
Comment 30 2012-10-08 20:54:27 PDT
Created attachment 167680 [details] Patch for landing
WebKit Review Bot
Comment 31 2012-10-09 01:00:50 PDT
Comment on attachment 167680 [details] Patch for landing Clearing flags on attachment: 167680 Committed r130732: <http://trac.webkit.org/changeset/130732>
WebKit Review Bot
Comment 32 2012-10-09 01:00:57 PDT
All reviewed patches have been landed. Closing bug.
Note You need to log in before you can comment on or make changes to this bug.