Bug 56465 - [GTK] svg/W3C-I18N tests have different results on 32-bits and 64-bits
Summary: [GTK] svg/W3C-I18N tests have different results on 32-bits and 64-bits
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebKitGTK (show other bugs)
Version: 528+ (Nightly build)
Hardware: PC OS X 10.5
: P2 Normal
Assignee: Nobody
URL:
Keywords:
Depends on:
Blocks: 62204
  Show dependency treegraph
 
Reported: 2011-03-16 08:45 PDT by Philippe Normand
Modified: 2012-10-05 13:27 PDT (History)
4 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Philippe Normand 2011-03-16 08:45:17 PDT
svg/W3C-I18N/g-dirLTR-ubNone.svg
svg/W3C-I18N/g-dirLTR-ubOverride.svg
svg/W3C-I18N/text-dirLTR-ubNone.svg
svg/W3C-I18N/text-dirLTR-ubOverride.svg	expected
svg/W3C-I18N/tspan-dirLTR-ubEmbed-in-rtl-context.svg
svg/W3C-I18N/tspan-dirLTR-ubNone-in-rtl-context.svg
svg/W3C-I18N/tspan-dirLTR-ubOverride-in-rtl-context.svg

fail currently on 32-bits Debug. Example of diff:


--- /home/slave/webkitgtk/gtk-linux-32-debug/build/layout-test-results/svg/W3C-I18N/g-dirLTR-ubNone-expected.txt	2011-03-16 07:34:08.327399579 -0700
+++ /home/slave/webkitgtk/gtk-linux-32-debug/build/layout-test-results/svg/W3C-I18N/g-dirLTR-ubNone-actual.txt	2011-03-16 07:34:08.327399579 -0700
@@ -6,9 +6,9 @@
       RenderSVGContainer {g} at (150,221) size 467x38
         RenderSVGText {text} at (90,133) size 280x22 contains 1 chunk(s)
           RenderSVGInlineText {#text} at (0,0) size 280x22
-            chunk 1 (middle anchor) text run 1 at (90.80,150.00) startOffset 0 endOffset 4 width 45.00: "W3C "
-            chunk 1 (middle anchor) text run 1 at (135.80,150.00) startOffset 0 endOffset 12 width 101.40 RTL: "\x{646}\x{634}\x{627}\x{637} \x{627}\x{644}\x{62A}\x{62F}\x{648}\x{64A}\x{644}"
-            chunk 1 (middle anchor) text run 1 at (237.20,150.00) startOffset 0 endOffset 15 width 132.00: " dirLTR ubNone!"
+            chunk 1 (middle anchor) text run 1 at (90.50,150.00) startOffset 0 endOffset 4 width 45.00: "W3C "
+            chunk 1 (middle anchor) text run 1 at (135.50,150.00) startOffset 0 endOffset 12 width 101.40 RTL: "\x{646}\x{634}\x{627}\x{637} \x{627}\x{644}\x{62A}\x{62F}\x{648}\x{64A}\x{644}"
+            chunk 1 (middle anchor) text run 1 at (236.90,150.00) startOffset 0 endOffset 15 width 132.60: " dirLTR ubNone!"
       RenderSVGText {text} at (20,170) size 86x13 contains 1 chunk(s)
         RenderSVGInlineText {#text} at (0,0) size 86x13
           chunk 1 text run 1 at (20.00,180.00) startOffset 0 endOffset 18 width 85.20: "Reference graphic:"

Will skip for now.
Comment 1 Philippe Normand 2011-03-16 08:48:11 PDT
Skipped in http://trac.webkit.org/changeset/81247
Comment 2 Martin Robinson 2011-03-29 14:39:40 PDT
Ccing a couple SVG guys. The issue here seems to be that debug 32-bit builds are showing < 1 pixel differences in output. The pixel results only show 0.01 percent difference (on Cairo that is essentially no difference).
Comment 3 Nikolas Zimmermann 2011-03-30 00:27:17 PDT
(In reply to comment #2)
> Ccing a couple SVG guys. The issue here seems to be that debug 32-bit builds are showing < 1 pixel differences in output. The pixel results only show 0.01 percent difference (on Cairo that is essentially no difference).

Same problem on mac, between my 32 and 64bit MacBooks.
.... Sad sad, but I'm not sure what to do about it atm.
Comment 4 Nikolas Zimmermann 2011-03-30 00:40:22 PDT
(In reply to comment #3)
> (In reply to comment #2)
> > Ccing a couple SVG guys. The issue here seems to be that debug 32-bit builds are showing < 1 pixel differences in output. The pixel results only show 0.01 percent difference (on Cairo that is essentially no difference).
> 
> Same problem on mac, between my 32 and 64bit MacBooks.
> .... Sad sad, but I'm not sure what to do about it atm.
Oops, I wanted to say, the pixel results differ, not the text results. No idea why text differs on Gtk...
Comment 5 Zan Dobersek 2012-10-05 13:27:34 PDT
All the tests listed (and other tests in svg/W3C-I18N as well) have been passing consistently on the GTK builders, co closing this bug.
http://test-results.appspot.com/dashboards/flakiness_dashboard.html#group=%40ToT%20-%20webkit.org&tests=svg%2FW3C-I18N