Can't you just post this in the bug? I fail to see why this should be
a topic for discussion on webkit-dev.
dave
(hy...@apple.com)
On Jul 5, 2009, at 1:18 PM, Vamsi Kalyan wrote:
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
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
_______________________________________________
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
