L. David Baron wrote:
I'm considering refactoring a good bit of nsHTMLReflowState (ComputeBlockBoxData, InitConstraints) plus things like nsImageFrame::GetDesiredSize that use NS_INTRINSICSIZE
Seconded!
* @param aAvailWidth The available width into which the element is * being placed (i.e., the width of its containing * block).
So this is not the same as the availWidth of a reflow state, correct? This is the value that should be used as a base for percentage widths, basically?
* @param aPadding The sum of the left and right margins of the
s/margin/padding/ I think this looks pretty reasonable...
One thing I was considering was whether I should pass the reflow state as a parameter or not. The advantage of doing so would be fewer parameters (and perhaps ease of depending on additional things in the reflow state) and perhaps the performance advantage of not re-retrieving the style structs. However, I consider ease of adding extra dependencies to be a significant disadvantage (it makes it harder to enforce invariants) -- especially dependencies on nsHTMLReflowState, which I'd like to get significantly smaller.
Would it make sense to split up the reflow state into two structs (one inheriting from the other), put the stuff we'd be OK with passing to this method in the ancestor struct, and make the arg to this method of the ancestor type? That way we could benefit from the style struct caching if needed, etc. If that would not be worth it, we might still want to consider passing in a struct holding those values instead of a bunch of different args.
I assume the actual implementations will make some use of static methods on nsLayoutUtils or nsHTMLReflowState or something?
-Boris _______________________________________________ dev-tech-layout mailing list [email protected] https://lists.mozilla.org/listinfo/dev-tech-layout
