23927 2009-02-12 10:16:44 -0800 LayoutTests for svg fail after TransformationMatrix changes 2011-11-11 07:28:17 -0800 1 1 1 Unclassified WebKit Tools / Tests 528+ (Nightly build) Mac OS X 10.5 RESOLVED DUPLICATE 47467 P2 Normal --- 1 cmarrin cmarrin davinci eric krit oliver simon.fraser zimmermann oldest_to_newest 109493 0 cmarrin 2009-02-12 10:16:44 -0800 Because of the change in TransformationMatrix from doing computations in floats to doubles, precision differences show up in LayoutTests as slightly different numeric values. Most of these are things like 0.00 vs -0.00 and 17s vs 172.00. Fixing DRT to get rid of these two differences will fix the problem in almost all tests The downside is that changing how numbers print out will require many test results to be redone. 109496 1 27605 cmarrin 2009-02-12 10:20:35 -0800 Created attachment 27605 Patch for getTransformToElement fix This patch fixes one test on PPC Mac 109499 2 27608 cmarrin 2009-02-12 10:28:55 -0800 Created attachment 27608 Patch to skip SVG tests until problem is resolved This patch skips 16 svg tests until the number printing problem is resolved 109508 3 27608 simon.fraser 2009-02-12 10:44:14 -0800 Comment on attachment 27608 Patch to skip SVG tests until problem is resolved r=me, but make sure you keep this bug open, and assign it to yourself. 109516 4 cmarrin 2009-02-12 11:25:51 -0800 Applied getTransfrmToElement patch Sending LayoutTests/ChangeLog Sending LayoutTests/svg/custom/getTransformToElement.svg Transmitting file data .. Committed revision 40914. 109517 5 cmarrin 2009-02-12 11:26:24 -0800 Applied patch to skip some tests Sending LayoutTests/ChangeLog Sending LayoutTests/platform/mac/Skipped Transmitting file data .. Committed revision 40915. 109687 6 cmarrin 2009-02-13 08:32:45 -0800 I'm leaving this bug open. LayoutTests are now clear (WRT these issues), but some tests are being skipped, so the underlying problem still needs to be resolved. 119363 7 27605 eric 2009-04-29 14:55:07 -0700 Comment on attachment 27605 Patch for getTransformToElement fix Clearing review flag to remove from commit queue. 119364 8 27608 eric 2009-04-29 14:55:14 -0700 Comment on attachment 27608 Patch to skip SVG tests until problem is resolved Clearing review flag to remove from commit queue. 176335 9 zimmermann 2010-01-02 10:07:54 -0800 Hm, any news regarding this bug? I'd love to see it resolved. The problem is the way Path::debugString() (which is used by DRT -> SVGRenderTreeAsText -> RenderPath -> Path::debugString()) works: it's manually traversing the path items, building up the d=".." string thatt will be dumped in the -expected.txt files (for any SVG test). We should make that code cross-platform (why should every platform have to write it's own debugString() method, that's only used for layout tests anyways), and fix the rounding issues alltogether. We shouldn't skip SVG tests for a long period like that :( 203467 10 davinci 2010-03-24 10:21:54 -0700 I'm also running into display problems with the precision of large numbers here: https://bugs.webkit.org/show_bug.cgi?id=25645 What would it involve to change Path::debugString() to output numbers in scientific (exponential) notation for sufficiently large (or small) numbers in a consistent manner across all platforms? Are people generally against this since it would mean rebaselining a bunch of tests? That seems better than skipping them. 203476 11 krit 2010-03-24 10:35:53 -0700 (In reply to comment #10) > I'm also running into display problems with the precision of large numbers > here: https://bugs.webkit.org/show_bug.cgi?id=25645 > > What would it involve to change Path::debugString() to output numbers in > scientific (exponential) notation for sufficiently large (or small) numbers in > a consistent manner across all platforms? Are people generally against this > since it would mean rebaselining a bunch of tests? That seems better than > skipping them. I don't believe that the issues here is relatet to the one in bug 25645. But to answer your question, you have to change the platform-specific debug infos at WebCore/platform/graphcis/<platform>/Path*.cpp But some platforms, like cairo, don't support float values, they use fixed point instead. So you would break many DRT-tests by changing debugString. 203481 12 simon.fraser 2010-03-24 10:39:25 -0700 I agree that making a cross-platform version of Path::debugString() makes the most sense. 203561 13 davinci 2010-03-24 13:51:44 -0700 (In reply to comment #11) > I don't believe that the issues here is relatet to the one in bug 25645. But to > answer your question, you have to change the platform-specific debug infos at > WebCore/platform/graphcis/<platform>/Path*.cpp > But some platforms, like cairo, don't support float values, they use fixed > point instead. So you would break many DRT-tests by changing debugString. It's unrelated except that they both output using debugString(). That's what I thought about debugString() -- that changing it would break everything. Thanks for confirming that. I guess what we should aim for is round-trip preservation of values, so if I enter 12345678901234567890 then debugString should output "12345678901234567890[.00]". That's probably very difficult to do. 203664 14 krit 2010-03-24 15:55:40 -0700 (In reply to comment #12) > I agree that making a cross-platform version of Path::debugString() makes the > most sense. Not sure if it makes sense and realy depends on how we are doing it. E.g. if we save every point , every line or curve or transformation in an extra array, we don't know what the different platforms are realy doing. The question is, if we care about the real output, or if we care about what webkit wants to draw (independent of what we see on the screen). Both things can be from interest. Note, that transformations on a path would also cause transformations on previous stored values on the array, for the platform independent solution. 204500 15 zimmermann 2010-03-26 04:35:25 -0700 Just brainstormed this again with Dirk and there's a new idea: How about utilizing the already present coordinate information (path segments + coordinates) from the SVG DOM when dumping the RenderPath debugString? Instead of pulling it from the engines (ask Cg for path segments..) we could ask just access the node() of the RenderPath, which is a SVGPathElement. This contains a SVGPathSegList with all necessary information. The only drawback is that we have to manually transform the coordinates into absolute coords on screen, to get the same results we dump now (same coord space). The benefit is that OpenVG which doesn't even offer access to the path segments can easily be supported. The drawback is that we loose information from the engine itself. We could do following: Keep the current debugString implementation seperated, implement a new cross-platfrom debugstring utiliyzing SVGPathSegList and compare the transformed coordinates from the engine and our internally stored coordinates from SVGPathSegList using a tolerance (aka. "fuzzy compare"). If we see significant deviations, we could dump two debug strings in the DRT results, indicating an error, if not we could just dump the cross-platform version. Details need to be worked out, but we think this may be the right step in the right direction. Comments appreciated! 290958 16 zimmermann 2010-10-07 06:12:21 -0700 I'm going to reenable the tests in question, it makes no sense to skip them just because of 0.0 vs -0.0 issues. The tests are helpful, and we want them nontheless. The debugString() problem is being worked on at the moment, and we need these tests to verify the problem is gone, see bug 47340. 500757 17 zimmermann 2011-11-11 07:28:17 -0800 Marked as duplicate of 47467. *** This bug has been marked as a duplicate of bug 47467 *** 27605 2009-02-12 10:20:35 -0800 2009-04-29 14:55:07 -0700 Patch for getTransformToElement fix 23927-getTransformToElement-fixed.patch text/plain 1480 cmarrin SW5kZXg6IExheW91dFRlc3RzL0NoYW5nZUxvZwo9PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBMYXlvdXRUZXN0cy9D aGFuZ2VMb2cJKHJldmlzaW9uIDQwOTEwKQorKysgTGF5b3V0VGVzdHMvQ2hhbmdlTG9nCSh3b3Jr aW5nIGNvcHkpCkBAIC0xLDMgKzEsMTMgQEAKKzIwMDktMDItMTIgIEFwcGxlICA8c2V0IEVNQUlM X0FERFJFU1MgZW52aXJvbm1lbnQgdmFyaWFibGU+CisKKyAgICAgICAgUmV2aWV3ZWQgYnkgTk9C T0RZIChPT1BTISkuCisKKyAgICAgICAgaHR0cHM6Ly9idWdzLndlYmtpdC5vcmcvc2hvd19idWcu Y2dpP2lkPTIzOTI3CisKKyAgICAgICAgVGhpcyBmaXhlcyBvbmUgdGVzdGNhc2Ugb24gUFBDIE1h YworCisgICAgICAgICogc3ZnL2N1c3RvbS9nZXRUcmFuc2Zvcm1Ub0VsZW1lbnQuc3ZnOgorCiAy MDA5LTAyLTEyICBBZGFtIFJvYmVuICA8YXJvYmVuQGFwcGxlLmNvbT4KIAogICAgICAgICBBZGQg c29tZSB0ZXN0cyB0aGF0IGZhaWwgZHVlIHRvIHVzaW5nIHRoZSB3cm9uZyBmb250IGZvciBIZWJy ZXcgdG8gdGhlCkluZGV4OiBMYXlvdXRUZXN0cy9zdmcvY3VzdG9tL2dldFRyYW5zZm9ybVRvRWxl bWVudC5zdmcKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PQotLS0gTGF5b3V0VGVzdHMvc3ZnL2N1c3RvbS9nZXRUcmFuc2Zv cm1Ub0VsZW1lbnQuc3ZnCShyZXZpc2lvbiA0MDkwOSkKKysrIExheW91dFRlc3RzL3N2Zy9jdXN0 b20vZ2V0VHJhbnNmb3JtVG9FbGVtZW50LnN2Zwkod29ya2luZyBjb3B5KQpAQCAtMTAsNyArMTAs NyBAQAogICAgICAgICBjdG0gPSByZWZlcmVuY2VFbGVtZW50LmdldFRyYW5zZm9ybVRvRWxlbWVu dChkb2N1bWVudC5nZXRFbGVtZW50QnlJZCgiZ3JvdXAyIikpOwogICAgICAgICBpZiAoY3RtLmEu dG9GaXhlZCgzKSA9PSAwLjM1NCAmJiBjdG0uYi50b0ZpeGVkKDMpID09IC0wLjM1NCAmJgogICAg ICAgICAgICAgY3RtLmMudG9GaXhlZCgzKSA9PSAwLjM1NCAmJiBjdG0uZC50b0ZpeGVkKDMpID09 IDAuMzU0ICYmCi0gICAgICAgICAgICBjdG0uZS50b0ZpeGVkKDMpID09IC03LjA3MSAmJiBjdG0u Zi50b0ZpeGVkKDE1KSA9PSAwLjApIHsKKyAgICAgICAgICAgIGN0bS5lLnRvRml4ZWQoMykgPT0g LTcuMDcxICYmIGN0bS5mLnRvRml4ZWQoOCkgPT0gMC4wKSB7CiAgICAgICAgICAgICBjdG0gPSBy ZWZlcmVuY2VFbGVtZW50LmdldFRyYW5zZm9ybVRvRWxlbWVudChkb2N1bWVudC5nZXRFbGVtZW50 QnlJZCgicmVkUmVjdCIpKTsKICAgICAgICAgICAgIGlmIChjdG0uYS50b0ZpeGVkKDMpID09IDAu MzU0ICYmIGN0bS5iLnRvRml4ZWQoMykgPT0gLTAuMzU0ICYmCiAgICAgICAgICAgICAgICAgY3Rt LmMudG9GaXhlZCgzKSA9PSAwLjM1NCAmJiBjdG0uZC50b0ZpeGVkKDMpID09IDAuMzU0ICYmCg== 27608 2009-02-12 10:28:55 -0800 2009-04-29 14:55:14 -0700 Patch to skip SVG tests until problem is resolved 23927-skip-svg-tests.patch text/plain 1634 cmarrin SW5kZXg6IExheW91dFRlc3RzL0NoYW5nZUxvZwo9PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBMYXlvdXRUZXN0cy9D aGFuZ2VMb2cJKHJldmlzaW9uIDQwOTExKQorKysgTGF5b3V0VGVzdHMvQ2hhbmdlTG9nCSh3b3Jr aW5nIGNvcHkpCkBAIC0xLDMgKzEsMTMgQEAKKzIwMDktMDItMTIgIEFwcGxlICA8c2V0IEVNQUlM X0FERFJFU1MgZW52aXJvbm1lbnQgdmFyaWFibGU+CisKKyAgICAgICAgUmV2aWV3ZWQgYnkgTk9C T0RZIChPT1BTISkuCisKKyAgICAgICAgaHR0cHM6Ly9idWdzLndlYmtpdC5vcmcvc2hvd19idWcu Y2dpP2lkPTIzOTI3CisKKyAgICAgICAgU2tpcCAxNiBTVkcgdGVzdHMgdGhhdCBmYWlsIG9uIFBQ QywgdW50aWwgcHJvYmxlbSBpcyByZXNvbHZlZAorCisgICAgICAgICogcGxhdGZvcm0vbWFjL1Nr aXBwZWQ6CisKIDIwMDktMDItMTIgIEFkYW0gUm9iZW4gIDxhcm9iZW5AYXBwbGUuY29tPgogCiAg ICAgICAgIEFkZCBzb21lIHRlc3RzIHRoYXQgZmFpbCBkdWUgdG8gdXNpbmcgdGhlIHdyb25nIGZv bnQgZm9yIEhlYnJldyB0byB0aGUKSW5kZXg6IExheW91dFRlc3RzL3BsYXRmb3JtL21hYy9Ta2lw cGVkCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT0KLS0tIExheW91dFRlc3RzL3BsYXRmb3JtL21hYy9Ta2lwcGVkCShyZXZp c2lvbiA0MDkwOSkKKysrIExheW91dFRlc3RzL3BsYXRmb3JtL21hYy9Ta2lwcGVkCSh3b3JraW5n IGNvcHkpCkBAIC00NiwzICs0NiwyMSBAQCB0YWJsZXMvbW96aWxsYV9leHBlY3RlZF9mYWlsdXJl cy9idWdzL2J1CiAKICMgaHR0cHM6Ly9idWdzLndlYmtpdC5vcmcvc2hvd19idWcuY2dpP2lkPTIx OTEzIFJlcGFpbnQgcGl4ZWwgdGVzdCBmYWlsdXJlCiBmYXN0L3JlcGFpbnQvYm9keS1iYWNrZ3Jv dW5kLWltYWdlLmh0bWwKKworIyBodHRwczovL2J1Z3Mud2Via2l0Lm9yZy9zaG93X2J1Zy5jZ2k/ aWQ9MjM5MjcgTGF5b3V0VGVzdHMgZm9yIHN2ZyBmYWlsIGFmdGVyIFRyYW5zZm9ybWF0aW9uTWF0 cml4IGNoYW5nZXMKK3N2Zy9XM0MtU1ZHLTEuMS9hbmltYXRlLWVsZW0tMzYtdC5zdmcKK3N2Zy9X M0MtU1ZHLTEuMS9hbmltYXRlLWVsZW0tODAtdC5zdmcKK3N2Zy9XM0MtU1ZHLTEuMS9hbmltYXRl LWVsZW0tODEtdC5zdmcKK3N2Zy9XM0MtU1ZHLTEuMS9hbmltYXRlLWVsZW0tODItdC5zdmcKK3N2 Zy9XM0MtU1ZHLTEuMS9jb29yZHMtdHJhbnMtMDEtYi5zdmcKK3N2Zy9XM0MtU1ZHLTEuMS9jb29y ZHMtdHJhbnMtMDItdC5zdmcKK3N2Zy9XM0MtU1ZHLTEuMS9wYWludGluZy1tYXJrZXItMDEtZi5z dmcKK3N2Zy9XM0MtU1ZHLTEuMS9wc2VydmVycy1ncmFkLTA5LWIuc3ZnCitzdmcvVzNDLVNWRy0x LjEvcHNlcnZlcnMtZ3JhZC0xMi1iLnN2Zworc3ZnL1czQy1TVkctMS4xL3BzZXJ2ZXJzLWdyYWQt MTctYi5zdmcKK3N2Zy9XM0MtU1ZHLTEuMS9zdHJ1Y3QtZ3JvdXAtMDMtdC5zdmcKK3N2Zy9jYXJ0 by5uZXQvc2xpZGVyLnN2Zworc3ZnL2NhcnRvLm5ldC90YWJncm91cC5zdmcKK3N2Zy9oaXhpZS9w ZXJmLzAwMS54bWwKK3N2Zy9oaXhpZS9wZXJmLzAwMi54bWwKKwo=