Bug 60209

Summary: Split findNextLineBreak into a LineBreaker class
Product: WebKit Reporter: Levi Weintraub <leviw>
Component: Layout and RenderingAssignee: Levi Weintraub <leviw>
Status: RESOLVED FIXED    
Severity: Normal CC: cmarcelo, commit-queue, eric, hyatt, mitz, rniwa
Priority: P2    
Version: 528+ (Nightly build)   
Hardware: All   
OS: All   
Bug Depends on:    
Bug Blocks: 57779    
Attachments:
Description Flags
Patch
none
Patch for landing none

Levi Weintraub
Reported 2011-05-04 14:12:33 PDT
Splitting findNextLineBreak into a separate class will make it much easier to further refactor the giant function by allowing its state to be kept in member variables accessible to new helper functions without having to pass them in giant parameter lists.
Attachments
Patch (21.13 KB, patch)
2011-05-04 14:41 PDT, Levi Weintraub 		no flags
DetailsFormatted DiffDiff
Patch for landing (19.85 KB, patch)
2011-05-04 15:10 PDT, Levi Weintraub 		no flags
DetailsFormatted DiffDiff
Show Obsolete (1) View All Add attachment proposed patch, testcase, etc.
Eric Seidel (no email)
Comment 1 2011-05-04 14:15:11 PDT
Yay!
Levi Weintraub
Comment 2 2011-05-04 14:41:08 PDT
Created attachment 92317 [details] Patch
Eric Seidel (no email)
Comment 3 2011-05-04 14:57:44 PDT
Comment on attachment 92317 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=92317&action=review Hm... LineBreaker seems like a class of logic, and the actual state will likely end up separate. Sorta like how BidiStatus is separate from the actual BidiResolver, and the Token is separate from the Tokenizer, etc. But I think this is moving us in a good direction! it's not clear what m_hyphenated and m_clear apply to. I assume the current line, but it would be nice to make that more clear some how. Again, tha tmay be part of some later state from state-machine split. :) > Source/WebCore/rendering/RenderBlockLineLayout.cpp:901 > + LineBreaker lb(this); I would have called this lineBreaker. :) > Source/WebCore/rendering/RenderBlockLineLayout.cpp:2333 > +// FIXME: The entire concept of the skipTrailingWhitespace function is flawed, since we really need to be building > +// line boxes even for containers that may ultimately collapse away. Otherwise we'll never get positioned > +// elements quite right. In other words, we need to build this function's work into the normal line > +// object iteration process. > +// NB. this function will insert any floating elements that would otherwise > +// be skipped but it will not position them. > +void RenderBlock::LineBreaker::skipTrailingWhitespace(InlineIterator& iterator, const LineInfo& lineInfo) > +{ > + while (!iterator.atEnd() && !requiresLineBox(iterator, lineInfo)) { I wouldn't have bothered moving these from their previous location.
Levi Weintraub
Comment 4 2011-05-04 15:02:37 PDT
Comment on attachment 92317 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=92317&action=review Thanks for the review! I'm going to take both of your suggestions before landing. >> Source/WebCore/rendering/RenderBlockLineLayout.cpp:901 >> + LineBreaker lb(this); > > I would have called this lineBreaker. :) Renaming it :) >> Source/WebCore/rendering/RenderBlockLineLayout.cpp:2333 >> + while (!iterator.atEnd() && !requiresLineBox(iterator, lineInfo)) { > > I wouldn't have bothered moving these from their previous location. Fair point. It needlessly clutters blame and all...
Levi Weintraub
Comment 5 2011-05-04 15:10:20 PDT
Created attachment 92324 [details] Patch for landing
WebKit Commit Bot
Comment 6 2011-05-04 17:01:21 PDT
Comment on attachment 92324 [details] Patch for landing Clearing flags on attachment: 92324 Committed r85810: <http://trac.webkit.org/changeset/85810>
WebKit Commit Bot
Comment 7 2011-05-04 17:01:27 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.