77947 - floating point math in CalcLineHeight() necessary?

Status: RESOLVED WONTFIX

(Core :: Layout: Block and Inline, defect)

Description

[Chris Waterson]

While profiling the test case in bug 56854, the floating point conversion done
in CalcLineHeight() jumped out as a major component of this routine's time. Is
it necessary? Can it be improved? (Refer to bug 56854 for details.)

Comment 1

[Asa Dotzler [:asa]]

Bugs targeted at mozilla1.0 without the mozilla1.0 keyword moved to mozilla1.0.1 
(you can query for this string to delete spam or retrieve the list of bugs I've 
moved)

Comment 2

[basic]

remove self

Comment 3

[Boris Zbarsky [:bzbarsky]]

.

Comment 4

[Randell Jesup [:jesup] (needinfo me)]

From looking, ComputeLineHeight generally can't avoid floats in the special cases, since it's dealing with float values and fontInflation.
The primary case of GetFontMetricsForComputedStyle() avoids unneeded float ops as far as is reasonable. I think we can close this.

NSCoords are ints and so the float calcs get rounded, though there's a "we'd like to make them floats someday" comment which likely goes back to the Netscape days and which would probably break a lot...

Comment 5

[Sean Voisen (:svoisen)]

Jonathan — Thoughts on closing this?

Comment 6

[Jonathan Kew [:jfkthame]]

:jesup is correct in comment 4, we can't simply remove all floating-point work from here, though we can (and do) avoid it in some cases. I don't think this is useful as it stands.

(I'm interested in more generally re-examining how line height is computed, particularly for 'normal', as this is a perennial source of compat/interop issues, but that's not this bug - and any revision to this will likely still include floating-point math in some way.)