WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED FIXED
167988
[css-grid] Move the track sizing algorithm to its own class
https://bugs.webkit.org/show_bug.cgi?id=167988
Summary
[css-grid] Move the track sizing algorithm to its own class
Sergio Villar Senin
Reported
2017-02-08 07:54:58 PST
[css-grid] Move the track sizing algorithm to its own class
Attachments
Patch
(163.27 KB, patch)
2017-02-08 08:56 PST
,
Sergio Villar Senin
no flags
Details
Formatted Diff
Diff
Patch
(163.36 KB, patch)
2017-02-13 07:13 PST
,
Sergio Villar Senin
no flags
Details
Formatted Diff
Diff
Patch
(163.36 KB, patch)
2017-02-13 08:05 PST
,
Sergio Villar Senin
no flags
Details
Formatted Diff
Diff
Patch
(163.36 KB, patch)
2017-02-14 07:48 PST
,
Sergio Villar Senin
no flags
Details
Formatted Diff
Diff
Archive of layout-test-results from ews115 for mac-elcapitan
(2.49 MB, application/zip)
2017-02-14 09:34 PST
,
Build Bot
no flags
Details
Patch
(163.37 KB, patch)
2017-02-15 11:27 PST
,
Sergio Villar Senin
rego
: review+
Details
Formatted Diff
Diff
Show Obsolete
(4)
View All
Add attachment
proposed patch, testcase, etc.
Sergio Villar Senin
Comment 1
2017-02-08 08:56:53 PST
Created
attachment 300905
[details]
Patch
Javier Fernandez
Comment 2
2017-02-08 13:48:17 PST
Comment on
attachment 300905
[details]
Patch View in context:
https://bugs.webkit.org/attachment.cgi?id=300905&action=review
I like how the algorithm is implemented now. Please, consider my comment about the Strategy pattern for future refactoring efforts.
> Source/WebCore/rendering/GridTrackSizingAlgorithm.cpp:65 > + return (m_growthLimit == infinity) ? m_baseSize : m_growthLimit;
Do we need this parenthesis ?
> Source/WebCore/rendering/GridTrackSizingAlgorithm.cpp:115 > +static GridTrackSizingDirection flowAwareDirectionForChild(const RenderGrid* grid, const RenderBox& child, GridTrackSizingDirection direction)
Either grid is defined as a reference of we need a nullcheck before using it.
> Source/WebCore/rendering/GridTrackSizingAlgorithm.cpp:186 > + index += index ? autoTrackStylesSize : 0;
Can index be a negative value ? If that's the case, wouldn't make more sense as follows ? if (std::abs(index) > 0) index += autoTrackStylesSize;
> Source/WebCore/rendering/GridTrackSizingAlgorithm.cpp:187 > + return autoTrackStyles[index];
I guess that autoTrackStylesSize ensures index is always a positive value, however, should we add an ASSERT here ?
> Source/WebCore/rendering/GridTrackSizingAlgorithm.cpp:280 > + GridItemWithSpan(RenderBox& gridItem, GridSpan span)
Shouldn't be const RenderBox& gridItem ?
> Source/WebCore/rendering/GridTrackSizingAlgorithm.cpp:822 > + : GridTrackSizingAlgorithmStrategy(algorithm) { }
Have you considered using Templates for defining the different strategies instead of class inheritance ? GridTrackSizingAlgorithmTemplate<Strategy>::operationXXX() { Strategy::operationXXX(); }
> Source/WebCore/rendering/GridTrackSizingAlgorithm.cpp:864 > + // TODO(svillar): we pass TrackSizing to gridTrackSize() because it does not really matter
This comment does not follow our style.
> Source/WebCore/rendering/GridTrackSizingAlgorithm.cpp:916 > +class DefiniteSizeStrategy final : public GridTrackSizingAlgorithmStrategy {
Either using templates or class inheritance, perhaps it'd be clearer to define the different strategies in different files.
Sergio Villar Senin
Comment 3
2017-02-13 07:07:10 PST
(In reply to
comment #2
)
> Comment on
attachment 300905
[details]
> Patch > > View in context: >
https://bugs.webkit.org/attachment.cgi?id=300905&action=review
> > I like how the algorithm is implemented now. Please, consider my comment > about the Strategy pattern for future refactoring efforts. > > > Source/WebCore/rendering/GridTrackSizingAlgorithm.cpp:65 > > + return (m_growthLimit == infinity) ? m_baseSize : m_growthLimit; > > Do we need this parenthesis ?
Nop, although I left that code unchanged, just moved it around.
> > Source/WebCore/rendering/GridTrackSizingAlgorithm.cpp:115 > > +static GridTrackSizingDirection flowAwareDirectionForChild(const RenderGrid* grid, const RenderBox& child, GridTrackSizingDirection direction) > > Either grid is defined as a reference of we need a nullcheck before using it.
I'll add an ASSERT
> > Source/WebCore/rendering/GridTrackSizingAlgorithm.cpp:186 > > + index += index ? autoTrackStylesSize : 0; > > Can index be a negative value ? If that's the case, wouldn't make more sense > as follows ? > > if (std::abs(index) > 0) > index += autoTrackStylesSize;
Haven't changed that code. And the answer is yes, it might be negative, that's why it's defined as int and not as unsigned as some other variables in that method.
> > Source/WebCore/rendering/GridTrackSizingAlgorithm.cpp:187 > > + return autoTrackStyles[index]; > > I guess that autoTrackStylesSize ensures index is always a positive value, > however, should we add an ASSERT here ?
Again I haven't changed that code. But I can add another assert if you want.
> > Source/WebCore/rendering/GridTrackSizingAlgorithm.cpp:280 > > + GridItemWithSpan(RenderBox& gridItem, GridSpan span) > > Shouldn't be const RenderBox& gridItem ?
I haven't checked all the usages of that call, but again unchanged code.
> > Source/WebCore/rendering/GridTrackSizingAlgorithm.cpp:822 > > + : GridTrackSizingAlgorithmStrategy(algorithm) { } > > Have you considered using Templates for defining the different strategies > instead of class inheritance ? > > GridTrackSizingAlgorithmTemplate<Strategy>::operationXXX() { > Strategy::operationXXX(); > }
Nice suggestion. I haven't, not sure what would be the benefit though.
> > Source/WebCore/rendering/GridTrackSizingAlgorithm.cpp:864 > > + // TODO(svillar): we pass TrackSizing to gridTrackSize() because it does not really matter > > This comment does not follow our style.
Ack.
> > Source/WebCore/rendering/GridTrackSizingAlgorithm.cpp:916 > > +class DefiniteSizeStrategy final : public GridTrackSizingAlgorithmStrategy { > > Either using templates or class inheritance, perhaps it'd be clearer to > define the different strategies in different files.
Not sure it pays off the burden. I'd say that we could consider that if they became large, but from the time being I think they're well located right next to the algorithm mainly because the algorithm and the strategies are very coupled.
Sergio Villar Senin
Comment 4
2017-02-13 07:13:36 PST
Created
attachment 301353
[details]
Patch
Sergio Villar Senin
Comment 5
2017-02-13 08:05:21 PST
Created
attachment 301356
[details]
Patch
Sergio Villar Senin
Comment 6
2017-02-14 07:48:59 PST
Created
attachment 301500
[details]
Patch Build fix
Build Bot
Comment 7
2017-02-14 09:34:38 PST
Comment on
attachment 301500
[details]
Patch
Attachment 301500
[details]
did not pass mac-debug-ews (mac): Output:
http://webkit-queues.webkit.org/results/3110573
New failing tests: fast/css-grid-layout/grid-item-end-after-get-set.html fast/css-grid-layout/grid-item-negative-integer-explicit-grid-resolution.html fast/css-grid-layout/grid-item-named-grid-line-resolution.html fast/css-grid-layout/grid-item-position-changed-dynamic.html fast/css-grid-layout/implicit-tracks-before-explicit.html fast/css-grid-layout/grid-item-negative-position-resolution.html fast/css-grid-layout/grid-item-area-get-set.html fast/css-grid-layout/grid-auto-columns-rows-get-set.html fast/css-grid-layout/grid-auto-flow-resolution.html fast/css-grid-layout/grid-item-start-before-get-set.html fast/css-grid-layout/grid-item-negative-indexes.html fast/css-grid-layout/grid-item-spanning-resolution.html fast/css-grid-layout/grid-item-unknown-named-grid-line-resolution.html fast/css-grid-layout/grid-positioned-items-within-grid-implicit-track.html
Build Bot
Comment 8
2017-02-14 09:34:42 PST
Created
attachment 301513
[details]
Archive of layout-test-results from ews115 for mac-elcapitan The attached test failures were seen while running run-webkit-tests on the mac-debug-ews. Bot: ews115 Port: mac-elcapitan Platform: Mac OS X 10.11.6
Sergio Villar Senin
Comment 9
2017-02-15 11:27:56 PST
Created
attachment 301637
[details]
Patch Fixed an error in a newly added ASSERT
Sergio Villar Senin
Comment 10
2017-02-15 11:28:58 PST
Ping reviewers. I know that the size of the patch makes it a bit scary but it's mostly moving code out of the RenderGrid to the new file plus some renames.
Manuel Rego Casasnovas
Comment 11
2017-02-21 01:22:05 PST
Comment on
attachment 301637
[details]
Patch View in context:
https://bugs.webkit.org/attachment.cgi?id=301637&action=review
Awesome job, just added a few nits here and there.
> Source/WebCore/ChangeLog:9 > + GridTrackSizingAlgorithm, making the RenderGrid more compact and easy to maintain. A nice
Nit: s/the RenderGrid/RenderGrid/
> Source/WebCore/rendering/GridTrackSizingAlgorithm.cpp:93 > +// Static helper methods //////////////////////////////////////////////
Mmmm, is this line properly formatted? I'm fine with having comments to separate the different parts of the class, but I'd use the standard format for comments (finishing the sentence with a "dot" too).
> Source/WebCore/rendering/GridTrackSizingAlgorithm.cpp:157 > +// GridTrackSizingAlgorithm private ///////////////////////////////////
Ditto.
> Source/WebCore/rendering/GridTrackSizingAlgorithm.cpp:633 > +double GridTrackSizingAlgorithm::computeFlexFactorUnitSize(const Vector<GridTrack>& tracks, double flexFactorSum, LayoutUnit& leftOverSpace, const Vector<unsigned, 8>& flexibleTracksIndexes, std::unique_ptr<TrackIndexSet> tracksToTreatAsInflexible) const
Nit: This line seems a bit longer than usual. :-)
> Source/WebCore/rendering/GridTrackSizingAlgorithm.cpp:695 > + // The function is not called if we don't have <flex> grid tracks
Nit: Missing dot after comment.
> Source/WebCore/rendering/GridTrackSizingAlgorithm.cpp:716 > +// GridTrackSizingAlgorithmStrategy ///////////////////////////////
Ditto.
> Source/WebCore/rendering/GridTrackSizingAlgorithm.cpp:976 > +// GridTrackSizingAlgorithm steps /////////////////////////////////
Ditto.
> Source/WebCore/rendering/GridTrackSizingAlgorithm.cpp:1109 > +// GridTrackSizingAlgorithm API ///////////////////////////////////
Ditto.
Sergio Villar Senin
Comment 12
2017-02-22 03:46:09 PST
Committed
r212823
: <
http://trac.webkit.org/changeset/212823
>
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