Hi, this post is related to issue https://bugs.webkit.org/show_bug.cgi?id=22759.
corresponding chrome issue is http://code.google.com/p/chromium/issues/detail?id=2019 This post discusses the issue using the reduction HTML file available on the issue. Following calculations calculate the expected results for the reduction HTML file attached to the issue. Root ListItem vertical size, "RLITotal" = 0.6em top padding + text line height + 0.7em bottom padding, where Text line height = 16px * 70/100 * 1.5 = 16.8 So "RLITotal" = 0.6 * 16 * 70 / 100 + 16.8 + 0.7 * 16 * 70 / 100 = 6.72 + 16.8 + 7.84 = 31.36 The absolute positioned popup list's vertical position = 2.8em = 2.8 * 16 * 70 /100 = 31.36 Though there is no gap between root element and popup, in Chrome we see some gap. What happens inside code during parsing the HTML file is that floating pointing number gets converted to integer without rounding off. So 6.72 becomes 6, 7.84 becomes 7 and 16.8 becomes 16 resulting in total for "RLITotal" as 29. And absolute vertical location for popup, 31.36 becomes 31. Clearly two pixel gap results because of this rounding off behaviour. Inside following function, int computedLineHeight() const { Length lh = lineHeight(); // Negative value means the line height is not set. Use the font's built-in spacing. if (lh.isNegative()) return font().lineSpacing(); if (lh.isPercent()) return lh.calcMinValue(fontSize(), true); return lh.value(); } The line, "return lh.calcMinValue(fontSize(), true);" was changed by adding true as second parameter, which lets the calcMinValue to round off the result to nearest integer. So in above example 16.82 becomes 17. But that will not be sufficient because we'll still have 1 pixel gap. So adding 0.5 to result before casting it to integer in the following function fixes the issue. This function is a generic function used during HTML/CSS file parsing. int CSSPrimitiveValue::computeLengthIntForLength(RenderStyle* style, double multiplier) { double result = computeLengthDouble(style, multiplier); // This conversion is imprecise, often resulting in values of, e.g., 44.99998. We // need to go ahead and round if we're really close to the next integer value. result += result < 0 ? -0.01 : +0.01; if (result > intMaxForLength || result < intMinForLength) return 0; return static_cast<int>(result); } I am not sure how critical the comment is in above function. Code rounds off only if it is too close to integer. Could anyone tell more about it, as in why 0.01 why not 0.5? Thanks.
_______________________________________________ webkit-dev mailing list [email protected] http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
