Title: [213008] trunk
- Revision
- 213008
- Author
- [email protected]
- Date
- 2017-02-25 14:18:23 -0800 (Sat, 25 Feb 2017)
Log Message
Text might wrap when its preferred logical width is used for sizing the containing block.
https://bugs.webkit.org/show_bug.cgi?id=168864
<rdar://problem/30690734>
Reviewed by Antti Koivisto.
Source/WebCore:
In certain cases we end up measuring a text run in 2 different ways.
1. preferred width computation -> slow path FontCascade::width()
2. line breaking logic -> fast path FontCascade::widthForSimpleText()
FontCascade::width() and ::widthForSimpleText() might return different results for the same run even when
the individual glyph widths are measured to be the same. It's because they run diffrent set of
arithmetics on the float values and for certain values these arithmetics produce different results due to the floating point
precision.
Since RenderText::computePreferredLogicalWidths() currently forces us to use the slow path
(to retrieve fontfallback and glyph overflow information) the only alternative solution is to turn off the fast path
for all runs that have been already measured using the slow path (which would be just wasteful).
Test: fast/text/fast-run-width-vs-slow-run-width.html
* platform/graphics/FontCascade.cpp:
(WebCore::FontCascade::widthForSimpleText): Mimics WidthIterator::applyFontTransforms. Use the same set of arithmetics here.
LayoutTests:
* fast/text/fast-run-width-vs-slow-run-width-expected.html: Added.
* fast/text/fast-run-width-vs-slow-run-width.html: Added.
Modified Paths
Added Paths
Diff
Modified: trunk/LayoutTests/ChangeLog (213007 => 213008)
--- trunk/LayoutTests/ChangeLog 2017-02-25 19:02:14 UTC (rev 213007)
+++ trunk/LayoutTests/ChangeLog 2017-02-25 22:18:23 UTC (rev 213008)
@@ -1,3 +1,14 @@
+2017-02-25 Zalan Bujtas <[email protected]>
+
+ Text might wrap when its preferred logical width is used for sizing the containing block.
+ https://bugs.webkit.org/show_bug.cgi?id=168864
+ <rdar://problem/30690734>
+
+ Reviewed by Antti Koivisto.
+
+ * fast/text/fast-run-width-vs-slow-run-width-expected.html: Added.
+ * fast/text/fast-run-width-vs-slow-run-width.html: Added.
+
2017-02-25 Michael Catanzaro <[email protected]>
Unreviewed GTK test gardening
Added: trunk/LayoutTests/fast/text/fast-run-width-vs-slow-run-width-expected.html (0 => 213008)
--- trunk/LayoutTests/fast/text/fast-run-width-vs-slow-run-width-expected.html (rev 0)
+++ trunk/LayoutTests/fast/text/fast-run-width-vs-slow-run-width-expected.html 2017-02-25 22:18:23 UTC (rev 213008)
@@ -0,0 +1,20 @@
+<!DOCTYPE html>
+<head>
+<title>This tests that fast and slow run width functions produce the same results.</title>
+<style>
+html {
+ font-family: "Helvetica Neue";
+ font-size: 62%;
+}
+
+div {
+ font-weight: 400;
+ font-size: 2.5rem;
+}
+</style>
+</head>
+<body>
+The text below should not wrap.<br>
+<div>alignment-baseline</div>
+</body>
+</html>
Added: trunk/LayoutTests/fast/text/fast-run-width-vs-slow-run-width.html (0 => 213008)
--- trunk/LayoutTests/fast/text/fast-run-width-vs-slow-run-width.html (rev 0)
+++ trunk/LayoutTests/fast/text/fast-run-width-vs-slow-run-width.html 2017-02-25 22:18:23 UTC (rev 213008)
@@ -0,0 +1,21 @@
+<!DOCTYPE html>
+<head>
+<title>This tests that fast and slow run width functions produce the same results.</title>
+<style>
+html {
+ font-family: "Helvetica Neue";
+ font-size: 62%;
+}
+
+div {
+ font-weight: 400;
+ font-size: 2.5rem;
+ display: inline-block;
+}
+</style>
+</head>
+<body>
+The text below should not wrap.<br>
+<div>alignment-baseline</div>
+</body>
+</html>
Modified: trunk/Source/WebCore/ChangeLog (213007 => 213008)
--- trunk/Source/WebCore/ChangeLog 2017-02-25 19:02:14 UTC (rev 213007)
+++ trunk/Source/WebCore/ChangeLog 2017-02-25 22:18:23 UTC (rev 213008)
@@ -1,3 +1,28 @@
+2017-02-25 Zalan Bujtas <[email protected]>
+
+ Text might wrap when its preferred logical width is used for sizing the containing block.
+ https://bugs.webkit.org/show_bug.cgi?id=168864
+ <rdar://problem/30690734>
+
+ Reviewed by Antti Koivisto.
+
+ In certain cases we end up measuring a text run in 2 different ways.
+ 1. preferred width computation -> slow path FontCascade::width()
+ 2. line breaking logic -> fast path FontCascade::widthForSimpleText()
+
+ FontCascade::width() and ::widthForSimpleText() might return different results for the same run even when
+ the individual glyph widths are measured to be the same. It's because they run diffrent set of
+ arithmetics on the float values and for certain values these arithmetics produce different results due to the floating point
+ precision.
+ Since RenderText::computePreferredLogicalWidths() currently forces us to use the slow path
+ (to retrieve fontfallback and glyph overflow information) the only alternative solution is to turn off the fast path
+ for all runs that have been already measured using the slow path (which would be just wasteful).
+
+ Test: fast/text/fast-run-width-vs-slow-run-width.html
+
+ * platform/graphics/FontCascade.cpp:
+ (WebCore::FontCascade::widthForSimpleText): Mimics WidthIterator::applyFontTransforms. Use the same set of arithmetics here.
+
2017-02-24 Simon Fraser <[email protected]>
Improve how multiple codegen-properties are handled in CSSProperties.json
Modified: trunk/Source/WebCore/platform/graphics/FontCascade.cpp (213007 => 213008)
--- trunk/Source/WebCore/platform/graphics/FontCascade.cpp 2017-02-25 19:02:14 UTC (rev 213007)
+++ trunk/Source/WebCore/platform/graphics/FontCascade.cpp 2017-02-25 22:18:23 UTC (rev 213008)
@@ -382,6 +382,8 @@
float FontCascade::widthForSimpleText(StringView text) const
{
+ if (text.isNull() || text.isEmpty())
+ return 0;
ASSERT(codePath(TextRun(text)) != FontCascade::Complex);
float* cacheEntry = m_fonts->widthCache().add(text, std::numeric_limits<float>::quiet_NaN());
if (cacheEntry && !std::isnan(*cacheEntry))
@@ -409,9 +411,12 @@
}
if (hasKerningOrLigatures) {
font.applyTransforms(&glyphs[0], &advances[0], glyphs.size(), enableKerning(), requiresShaping());
- runWidth = 0;
+ // This is needed only to match the result of the slow path. Same glyph widths but different floating point arithmentics can
+ // produce different run width.
+ float runWidthDifferenceWithTransformApplied = -runWidth;
for (auto& advance : advances)
- runWidth += advance.width();
+ runWidthDifferenceWithTransformApplied += advance.width();
+ runWidth += runWidthDifferenceWithTransformApplied;
}
if (cacheEntry)
_______________________________________________
webkit-changes mailing list
[email protected]
https://lists.webkit.org/mailman/listinfo/webkit-changes
