RESOLVED INVALID 11607
Possible optimization in RenderBlock::calcMinMaxWidth() 
https://bugs.webkit.org/show_bug.cgi?id=11607
Summary Possible optimization in RenderBlock::calcMinMaxWidth()
mitz
Reported 2006-11-15 15:24:45 PST
RenderBlock::calcMinMaxWidth() shouldn't call calcInlineMinMaxWidth/calcBlockMinMaxWidth (which iterate over all children) if it's not a table cell and has fixed positive width, since in that case it overwrites m_minWidth and m_maxWidth anyway. This is a fairly common case, and a very easy fix that could improve performance. I think this also applies to RenderFlexibleBox.
Attachments
Possible patch adapting the fix from Bug 12049. (2.04 KB, patch)
2007-04-12 01:32 PDT, Brian Heung 		hyatt: review-
DetailsFormatted DiffDiff
View All Add attachment proposed patch, testcase, etc.
mitz
Comment 1 2007-01-01 09:31:10 PST
I forgot about this bug when I filed bug 12049. Leaving this one open for the RenderFlexibleBox stuff. Also see other comments in bug 12049.
Brian Heung
Comment 2 2007-04-12 01:32:07 PDT
Created attachment 14016 [details] Possible patch adapting the fix from Bug 12049. I think this might be correct. I ran the layout regression tests and there were no failures.
Dave Hyatt
Comment 3 2007-04-18 13:27:42 PDT
Comment on attachment 14016 [details] Possible patch adapting the fix from Bug 12049. The way flexible boxes are eventually going to work is that width will not dictate the minwidth or maxwidth. That makes this optimization (eventually) pretty irrelevant for flexboxes. Also a flexbox can't ever be a table cell so the !isTableCell() bit is unnecessary.
Ahmad Saleem
Comment 4 2023-09-20 08:15:09 PDT
@Alan - this optimization is still applicable or we can close this?
zalan
Comment 5 2023-09-28 07:21:55 PDT
(In reply to Ahmad Saleem from comment #4) > @Alan - this optimization is still applicable or we can close this? looks dated to me.
Note You need to log in before you can comment on or make changes to this bug.