Bug 60209 - Split findNextLineBreak into a LineBreaker class
Summary: Split findNextLineBreak into a LineBreaker class
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: Layout and Rendering (show other bugs)
Version: 528+ (Nightly build)
Hardware: All All
: P2 Normal
Assignee: Levi Weintraub
URL:
Keywords:
Depends on:
Blocks: 57779
  Show dependency treegraph
 
Reported: 2011-05-04 14:12 PDT by Levi Weintraub
Modified: 2011-05-04 17:01 PDT (History)
6 users (show)

See Also:


Attachments
Patch (21.13 KB, patch)
2011-05-04 14:41 PDT, Levi Weintraub
no flags Details | Formatted Diff | Diff
Patch for landing (19.85 KB, patch)
2011-05-04 15:10 PDT, Levi Weintraub
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Levi Weintraub 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.
Comment 1 Eric Seidel (no email) 2011-05-04 14:15:11 PDT
Yay!
Comment 2 Levi Weintraub 2011-05-04 14:41:08 PDT
Created attachment 92317 [details]
Patch
Comment 3 Eric Seidel (no email) 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.
Comment 4 Levi Weintraub 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...
Comment 5 Levi Weintraub 2011-05-04 15:10:20 PDT
Created attachment 92324 [details]
Patch for landing
Comment 6 WebKit Commit Bot 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>
Comment 7 WebKit Commit Bot 2011-05-04 17:01:27 PDT
All reviewed patches have been landed.  Closing bug.