67601 2011-09-05 06:58:35 -0700 Return to transform multiplication: motion transform * other transforms 2019-10-22 07:17:05 -0700 1 1 1 Unclassified WebKit SVG 528+ (Nightly build) Unspecified Unspecified REOPENED P2 Normal --- 41761 1 krit webkit-unassigned longsonr shanestephens zimmermann oldest_to_newest 462148 0 krit 2011-09-05 06:58:35 -0700 Right now we take the current transform of a transformable element, post multiply the animation transform, post multiply the motion transform. While the spec demands us to do so, no other SVG viewer is doing it that way. Writing a patch to return to our old behavior (motion transform * transform * animation transform) right now. This was realized by other viewers as well. (Opera, FF, Batik ... all use other transform mulitplications. But none of these viewers match the behavior of the spec). We will pass two more tests on SVG W3C test suite. 462254 1 106357 krit 2011-09-05 14:00:05 -0700 Created attachment 106357 Patch 462396 2 106357 zimmermann 2011-09-06 00:29:33 -0700 Comment on attachment 106357 Patch Looks reasonable, r=me. Is Shane CC'ed, btw? I'd like to let him know that this has changed again. 462419 3 106357 krit 2011-09-06 01:17:22 -0700 Comment on attachment 106357 Patch Clearing flags on attachment: 106357 Committed r94558: <http://trac.webkit.org/changeset/94558> 462420 4 krit 2011-09-06 01:17:30 -0700 All reviewed patches have been landed. Closing bug. 462422 5 shanestephens 2011-09-06 01:20:21 -0700 This is one of those funny situations where neither the specified behaviour nor the current behaviour of Opera, FF, Batik, etc. makes sense - there are solid examples of unexpected things happening in each case. With this in mind I elected to follow the specification rather than current practice of other browsers (I also did this because it appeared that the code was inadvertently doing the wrong thing due to the fact that WebKit's matrix multiply operator was using operands in the wrong order). I also emailed www-svg with a query about what was appropriate: http://lists.w3.org/Archives/Public/www-svg/2010Dec/0033.html. This email generated a pretty long discussion, which as far as I can tell is ongoing - this is a genuinely difficult situation to resolve. I don't oppose returning WebKit to the behaviour exemplified by the current patch, although I would prefer we await final resolution from the SVG WG. If you're interested in specific examples of what breaks each way, let me know and I'll spend some time putting something together for this bug. 462423 6 shanestephens 2011-09-06 01:21:03 -0700 Not sure if I should be reopening this or not, feel free to close if this was inappropriate. 462427 7 krit 2011-09-06 01:51:20 -0700 (In reply to comment #5) > This is one of those funny situations where neither the specified behaviour nor the current behaviour of Opera, FF, Batik, etc. makes sense - there are solid examples of unexpected things happening in each case. > > With this in mind I elected to follow the specification rather than current practice of other browsers (I also did this because it appeared that the code was inadvertently doing the wrong thing due to the fact that WebKit's matrix multiply operator was using operands in the wrong order). I also emailed www-svg with a query about what was appropriate: http://lists.w3.org/Archives/Public/www-svg/2010Dec/0033.html. This email generated a pretty long discussion, which as far as I can tell is ongoing - this is a genuinely difficult situation to resolve. The discussion is still open. But their is no progress on it right now. But their seems to be at least one consensus: The specified behavior shouldn't be used. Other SVG viewers already followed the old behavior of WebKit. In a short testing it seems FireFox follows WebKit as well. The same for Abbra. Given the fact that Firefox is the SVG viewer with the most users on the desktop market, it makes sense to follow them here. We would get a lot of negative feedback if we do something different than Opera or Firefox for the simple test cases like the two tests on the official test suite -- even if we follow the specification. And I hope that we can get back to the discussion on www-svg with this change. Once all major SVG viewers reach a consensus, we can switch to any other behavior. And that is more important to follow the spec. All implementers are members of the SVG WG. Shouldn't be hard to change the spec at this point :) > > I don't oppose returning WebKit to the behaviour exemplified by the current patch, although I would prefer we await final resolution from the SVG WG. Like I said, I hope that we get progress on this topic again now. > > If you're interested in specific examples of what breaks each way, let me know and I'll spend some time putting something together for this bug. Oh of course. I am writing a mail to www-svg at the moment. I'll describe our current behavior in detail. If you see more differences across viewers, just post them on www-svg! 462450 8 shanestephens 2011-09-06 03:42:07 -0700 It's not really my fight, but my sense was that neither the specified behavior nor the tested behavior was optimal. It's a while since I've looked at this, but here goes: If I do: <g transform="translate(300, 30)"> <rect width="40" height="40" fill="green"></rect> <animateMotion dur="1s" repeatCount="1" rotate="auto" path="M 100,250 C 100,50 400,50 400,250"></animateMotion> </g> Then what firefox does is premultiply the supplemental transform from animateMotion. At the beginning of the path, this equates to a translate of (100, 250) and a rotation of approximately -90, so we get: translate(100, 250) rotate(-90) translate(300, 30) = translate(-50, 270) rotate(-90) Which is weird. On the other hand, if rotate="auto" is taken away, we get: translate(100, 250) translate(300, 30) = translate(400, 280) So the essential weirdness of premultiplication is that the container transform is used in the wrong place, which results in strange outcomes. I felt at the time that wildly different locations depending on whether rotate="auto" was set or not was worse than the alternatives. On the other hand, if you postmultiply the supplemental transform as currently specified, then something like: <g> <rect width="40" height="40" fill="green"></rect> <animateMotion dur="1s" repeatCount="1" path="M 100,250 C 100,50 400,50 400,250"></animateMotion> <animateTransform attributeName="transform" type="rotate" from="-30" to="0" begin="0s" dur="1s" fill="freeze"/> </g> behaves oddly because the animateTransform rotation affects the animateMotion translation even though it's specified after it. Neither the specified behavior nor the current favorite behavior (which is apparently an artifact of Adobe's that has spread to the other implementations) really does the right thing. Now what I'd like to see is for animateMotion to work off the CTM in the same way that animateTransform does, which would mean that there wouldn't be a supplemental transform to pre- or post- multiply, and this problem would go away. Apparently this is hard for other reasons but I've never seen a clear explanation of why. 462454 9 krit 2011-09-06 04:19:23 -0700 (In reply to comment #8) > It's not really my fight, but my sense was that neither the specified behavior nor the tested behavior was optimal. It's a while since I've looked at this, but here goes: > > If I do: > > <g transform="translate(300, 30)"> > <rect width="40" height="40" fill="green"></rect> > <animateMotion dur="1s" repeatCount="1" rotate="auto" path="M > 100,250 C 100,50 400,50 400,250"></animateMotion> > </g> > > Then what firefox does is premultiply the supplemental transform from animateMotion. At the beginning of the path, this equates to a translate of (100, 250) and a rotation of approximately -90, so we get: > > translate(100, 250) rotate(-90) translate(300, 30) > = > translate(-50, 270) rotate(-90) Yes that is right: animate motion * animate rotation * transform. Even if I agree the premultiplication of animate motion is not ideally, Firefox and WebKit trunk animations look identical now. So we have at least three viewers (with Abbas) that perform identically. > > Which is weird. On the other hand, if rotate="auto" is taken away, we get: > > translate(100, 250) translate(300, 30) > = > translate(400, 280) Thats correct as well. > > So the essential weirdness of premultiplication is that the container transform is used in the wrong place, which results in strange outcomes. I felt at the time that wildly different locations depending on whether rotate="auto" was set or not was worse than the alternatives. > > On the other hand, if you postmultiply the supplemental transform as currently specified, then something like: > > <g> > <rect width="40" height="40" fill="green"></rect> > <animateMotion dur="1s" repeatCount="1" path="M > 100,250 C 100,50 400,50 400,250"></animateMotion> > <animateTransform attributeName="transform" type="rotate" from="-30" to="0" begin="0s" dur="1s" fill="freeze"/> > </g> > > behaves oddly because the animateTransform rotation affects the animateMotion translation even though it's specified after it. Neither the specified behavior nor the current favorite behavior (which is apparently an artifact of Adobe's that has spread to the other implementations) really does the right thing. > > Now what I'd like to see is for animateMotion to work off the CTM in the same way that animateTransform does, which would mean that there wouldn't be a supplemental transform to pre- or post- multiply, and this problem would go away. Apparently this is hard for other reasons but I've never seen a clear explanation of why. I totally agree! But right now a common solution is more important than different solutions across all viewers (where just one viewer has the current specified behavior). This would just lead into resigned web developers and they don't use even one of the solutions. We can just try to get this problem on the agenda of one of the next SVG telcons. 462460 10 shanestephens 2011-09-06 04:34:00 -0700 Sounds good :) BTW I think Opera's behavior is different to everyone else's - from memory they actually implement animateMotion in the CTM (i.e. our hypothetical desired solution), but I could be wrong. 463227 11 krit 2011-09-07 01:19:07 -0700 *** Bug 52843 has been marked as a duplicate of this bug. *** 469056 12 longsonr 2011-09-17 01:58:22 -0700 (In reply to comment #9) > > Yes that is right: animate motion * animate rotation * transform. Even if I agree the premultiplication of animate motion is not ideally, Firefox and WebKit trunk animations look identical now. So we have at least three viewers (with Abbas) that perform identically. Not since firefox changed to match you last week https://bugzilla.mozilla.org/show_bug.cgi?id=665392 I expect we'll move back to the status quo again though. > I totally agree! But right now a common solution is more important than different solutions across all viewers (where just one viewer has the current specified behavior). This would just lead into resigned web developers and they don't use even one of the solutions. We can just try to get this problem on the agenda of one of the next SVG telcons. Indeed. 469135 13 krit 2011-09-17 21:09:59 -0700 (In reply to comment #12) > (In reply to comment #9) > > > > Yes that is right: animate motion * animate rotation * transform. Even if I agree the premultiplication of animate motion is not ideally, Firefox and WebKit trunk animations look identical now. So we have at least three viewers (with Abbas) that perform identically. > > Not since firefox changed to match you last week https://bugzilla.mozilla.org/show_bug.cgi?id=665392 I expect we'll move back to the status quo again though. Oh, bad timing :). I checked the behavior of a Firefox nightly right before switching back to our previous behavior. As I noted on the www-svg mailing list, I do not prefer to premultiply animate motion + rotation. Our intermediate solution (the specified solution) is much easier to understand for web developers IMHO (see comment #8). The solution that I prefer most is following the sandwich model (like we do for every other animated type) and not to define a special order for multiplication. > > > I totally agree! But right now a common solution is more important than different solutions across all viewers (where just one viewer has the current specified behavior). This would just lead into resigned web developers and they don't use even one of the solutions. We can just try to get this problem on the agenda of one of the next SVG telcons. > > Indeed. I fear that the SVG WG is not willing to change the specification text on SVG animations and replace it by CSS animations completely instead. 469148 14 longsonr 2011-09-17 23:53:20 -0700 (In reply to comment #13) > (In reply to comment #12) > > (In reply to comment #9) > > > > > > Yes that is right: animate motion * animate rotation * transform. Even if I agree the premultiplication of animate motion is not ideally, Firefox and WebKit trunk animations look identical now. So we have at least three viewers (with Abbas) that perform identically. > > > > Not since firefox changed to match you last week https://bugzilla.mozilla.org/show_bug.cgi?id=665392 I expect we'll move back to the status quo again though. > > Oh, bad timing :). I checked the behavior of a Firefox nightly right before switching back to our previous behavior. As I noted on the www-svg mailing list, I do not prefer to premultiply animate motion + rotation. Our intermediate solution (the specified solution) is much easier to understand for web developers IMHO (see comment #8). > The patch in https://bugzilla.mozilla.org/show_bug.cgi?id=665392 has just come back out of the firefox codebase. It only landed a few days ago. I still think firefox needs to change though so I don't think that's the end of it on our end. 106357 2011-09-05 14:00:05 -0700 2011-09-06 01:17:22 -0700 Patch bug-67601-20110905230002.patch text/plain 9118 krit SW5kZXg6IFNvdXJjZS9XZWJDb3JlL0NoYW5nZUxvZwo9PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBTb3VyY2UvV2Vi Q29yZS9DaGFuZ2VMb2cJKHJldmlzaW9uIDk0NTM3KQorKysgU291cmNlL1dlYkNvcmUvQ2hhbmdl TG9nCSh3b3JraW5nIGNvcHkpCkBAIC0xLDMgKzEsMzQgQEAKKzIwMTEtMDktMDUgIERpcmsgU2No dWx6ZSAgPGtyaXRAd2Via2l0Lm9yZz4KKworICAgICAgICBSZXR1cm4gdG8gdHJhbnNmb3JtIG11 bHRpcGxpY2F0aW9uOiBtb3Rpb24gdHJhbnNmb3JtICogb3RoZXIgdHJhbnNmb3JtcworICAgICAg ICBodHRwczovL2J1Z3Mud2Via2l0Lm9yZy9zaG93X2J1Zy5jZ2k/aWQ9Njc2MDEKKworICAgICAg ICBSZXZpZXdlZCBieSBOT0JPRFkgKE9PUFMhKS4KKyAgICAgICAgCisgICAgICAgIFJpZ2h0IG5v dyB3ZSB0YWtlIHRoZSBjdXJyZW50IHRyYW5zZm9ybSBvZiBhIHRyYW5zZm9ybWFibGUgU1ZHIGVs ZW1lbnQsIHBvc3QgbXVsdGlwbHkgdGhlIGFuaW1hdGlvbiB0cmFuc2Zvcm0KKyAgICAgICAgYW5k IHBvc3QgbXVsdGlwbHkgdGhlIG1vdGlvbiB0cmFuc2Zvcm0gdG8gdGhlIG90aGVyIGJvdGg6CisK KyAgICAgICAgICB0cmFuc2Zvcm0gKiBhbmltYXRpb24gdHJhbnNmb3JtICogbW90aW9uIHRyYW5z Zm9ybQorCisgICAgICAgIFdlIHN3aXRjaGVkIHRvIHRoaXMgYmVoYXZpb3Igd2l0aCB0aGUgY2xl YW4gdXAgb2YgQWZmaW5lVHJhbnNmb3JtLgorICAgICAgICBXaGlsZSB0aGUgc3BlY2lmaWNhdGlv biBvZiBTVkcgZGVtYW5kcyB1cyB0byBkbyBzbywgbm8gb3RoZXIgU1ZHIHZpZXdlciBpcyBkb2lu ZyBpdCB0aGF0IHdheS4gTm93IHN3aXRjaGluZyBiYWNrIHRvOgorCisgICAgICAgICAgbW90aW9u IHRyYW5zZm9ybSAqIHRyYW5zZm9ybSAqIGFuaW1hdGlvbiB0cmFuc2Zvcm0KKworICAgICAgICBU aGlzIGlzIGRvbmUgYnkgb3RoZXIgU1ZHIHZpZXdlcnMgYXMgd2VsbC4gV2hpbGUgdGhlaXIgaXMg bm8gY29uc2Vuc2UgYWJvdXQgaG93IHRvIG11bHRpcGx5IHRoZSBkaWZmZXJlbnQgdHJhbnNmb3Jt cworICAgICAgICBvbiB0aGUgU1ZHIFdHLCB0aGVpciBpcyBhIGNvbnNlbnNlIHRoYXQgdGhlIGN1 cnJlbnQgc3BlY2lmaWVkIGJlaGF2aW9yIGlzIHVud2FudGVkLiBTZWUKKyAgICAgICAgaHR0cDov L2xpc3RzLnczLm9yZy9BcmNoaXZlcy9QdWJsaWMvd3d3LXN2Zy8yMDExSmFuLzAwNTUuaHRtbCBm b3IgbW9yZSBkZXRhaWxzLgorCisgICAgICAgIFdlIHBhc3MgdGhlIGZvbGxvd2luZyB0ZXN0cyBv ZiB0aGUgb2ZmaWNpYWwgVzNDIFNWRyB0ZXN0IHN1aXRlIGFnYWluIG5vdzoKKworICAgICAgICAt IGFuaW1hdGUtZWxlbS0yNC10LnN2ZworICAgICAgICAtIGFuaW1hdGUtZWxlbS0zMC10LnN2Zwor CisgICAgICAgICogc3ZnL1NWR1N0eWxlZFRyYW5zZm9ybWFibGVFbGVtZW50LmNwcDoKKyAgICAg ICAgKFdlYkNvcmU6OlNWR1N0eWxlZFRyYW5zZm9ybWFibGVFbGVtZW50OjphbmltYXRlZExvY2Fs VHJhbnNmb3JtKToKKyAgICAgICAgKiBzdmcvU1ZHVGV4dEVsZW1lbnQuY3BwOgorICAgICAgICAo V2ViQ29yZTo6U1ZHVGV4dEVsZW1lbnQ6OmFuaW1hdGVkTG9jYWxUcmFuc2Zvcm0pOgorCiAyMDEx LTA5LTA1ICBOb2VsIEdvcmRvbiAgPG5vZWwuZ29yZG9uQGdtYWlsLmNvbT4KIAogICAgICAgICBb Y2hyb21pdW0gc2tpYV0gSlBFR0ltYWdlRW5jb2RlcjogaG9pc3QgY29udGFudHMgb3V0IG9mIHRo ZSBlbmNvZGluZyBsb29wCkluZGV4OiBTb3VyY2UvV2ViQ29yZS9zdmcvU1ZHU3R5bGVkVHJhbnNm b3JtYWJsZUVsZW1lbnQuY3BwCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIFNvdXJjZS9XZWJDb3JlL3N2Zy9TVkdT dHlsZWRUcmFuc2Zvcm1hYmxlRWxlbWVudC5jcHAJKHJldmlzaW9uIDk0NDkyKQorKysgU291cmNl L1dlYkNvcmUvc3ZnL1NWR1N0eWxlZFRyYW5zZm9ybWFibGVFbGVtZW50LmNwcAkod29ya2luZyBj b3B5KQpAQCAtNjUsNyArNjUsNyBAQCBBZmZpbmVUcmFuc2Zvcm0gU1ZHU3R5bGVkVHJhbnNmb3Jt YWJsZUVsCiAgICAgQWZmaW5lVHJhbnNmb3JtIG1hdHJpeDsKICAgICB0cmFuc2Zvcm0oKS5jb25j YXRlbmF0ZShtYXRyaXgpOwogICAgIGlmIChtX3N1cHBsZW1lbnRhbFRyYW5zZm9ybSkKLSAgICAg ICAgbWF0cml4ICo9ICptX3N1cHBsZW1lbnRhbFRyYW5zZm9ybTsKKyAgICAgICAgcmV0dXJuICpt X3N1cHBsZW1lbnRhbFRyYW5zZm9ybSAqIG1hdHJpeDsKICAgICByZXR1cm4gbWF0cml4OwogfQog CkluZGV4OiBTb3VyY2UvV2ViQ29yZS9zdmcvU1ZHVGV4dEVsZW1lbnQuY3BwCj09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0K LS0tIFNvdXJjZS9XZWJDb3JlL3N2Zy9TVkdUZXh0RWxlbWVudC5jcHAJKHJldmlzaW9uIDk0NDky KQorKysgU291cmNlL1dlYkNvcmUvc3ZnL1NWR1RleHRFbGVtZW50LmNwcAkod29ya2luZyBjb3B5 KQpAQCAtMTEzLDcgKzExMyw3IEBAIEFmZmluZVRyYW5zZm9ybSBTVkdUZXh0RWxlbWVudDo6YW5p bWF0ZWQKICAgICBBZmZpbmVUcmFuc2Zvcm0gbWF0cml4OwogICAgIHRyYW5zZm9ybSgpLmNvbmNh dGVuYXRlKG1hdHJpeCk7CiAgICAgaWYgKG1fc3VwcGxlbWVudGFsVHJhbnNmb3JtKQotICAgICAg ICBtYXRyaXggKj0gKm1fc3VwcGxlbWVudGFsVHJhbnNmb3JtOworICAgICAgICByZXR1cm4gKm1f c3VwcGxlbWVudGFsVHJhbnNmb3JtICogbWF0cml4OwogICAgIHJldHVybiBtYXRyaXg7CiB9CiAK SW5kZXg6IExheW91dFRlc3RzL0NoYW5nZUxvZwo9PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBMYXlvdXRUZXN0cy9D aGFuZ2VMb2cJKHJldmlzaW9uIDk0NTM3KQorKysgTGF5b3V0VGVzdHMvQ2hhbmdlTG9nCSh3b3Jr aW5nIGNvcHkpCkBAIC0xLDMgKzEsMjQgQEAKKzIwMTEtMDktMDUgIERpcmsgU2NodWx6ZSAgPGty aXRAd2Via2l0Lm9yZz4KKworICAgICAgICBSZXR1cm4gdG8gdHJhbnNmb3JtIG11bHRpcGxpY2F0 aW9uOiBtb3Rpb24gdHJhbnNmb3JtICogb3RoZXIgdHJhbnNmb3JtcworICAgICAgICBodHRwczov L2J1Z3Mud2Via2l0Lm9yZy9zaG93X2J1Zy5jZ2k/aWQ9Njc2MDEKKworICAgICAgICBSZXZpZXdl ZCBieSBOT0JPRFkgKE9PUFMhKS4KKyAgICAgICAgCisgICAgICAgIENoYW5nZSB0aGUgZXhwZWN0 ZWQgcmVzdWx0cyBvZiBuZXN0ZWQgdHJhbnNmb3JtYXRpb25zIHRvIG1hdGNoIG5ldyBiZWhhdmlv cgorICAgICAgICBvbiBtYXRyaWNlcyBtdWx0aXBsaWNhdGlvbnMuCisKKyAgICAgICAgKiBzdmcv YW5pbWF0aW9ucy9hbmltYXRlLXBhdGgtbmVzdGVkLXRyYW5zZm9ybXMtZXhwZWN0ZWQudHh0Ogor ICAgICAgICAqIHN2Zy9hbmltYXRpb25zL2FuaW1hdGUtdGV4dC1uZXN0ZWQtdHJhbnNmb3Jtcy1l eHBlY3RlZC50eHQ6CisgICAgICAgICogc3ZnL2FuaW1hdGlvbnMvc2NyaXB0LXRlc3RzL2FuaW1h dGUtcGF0aC1uZXN0ZWQtdHJhbnNmb3Jtcy5qczoKKyAgICAgICAgKHN0YXJ0U2FtcGxlKToKKyAg ICAgICAgKGVuZFNhbXBsZSk6CisgICAgICAgICogc3ZnL2FuaW1hdGlvbnMvc2NyaXB0LXRlc3Rz L2FuaW1hdGUtdGV4dC1uZXN0ZWQtdHJhbnNmb3Jtcy5qczoKKyAgICAgICAgKHN0YXJ0U2FtcGxl KToKKyAgICAgICAgKGVuZFNhbXBsZSk6CisgICAgICAgICogc3ZnL2FuaW1hdGlvbnMvc3ZndHJh bnNmb3JtLWFuaW1hdGlvbi1kaXNjcmV0ZS1leHBlY3RlZC50eHQ6CisgICAgICAgICogc3ZnL2Fu aW1hdGlvbnMvc3ZndHJhbnNmb3JtLWFuaW1hdGlvbi1kaXNjcmV0ZS5odG1sOgorCiAyMDExLTA5 LTA1ICBKb2huIEtub3R0ZW5iZWx0ICA8amtub3R0ZW5AY2hyb21pdW0ub3JnPgogCiAgICAgICAg IFRha2UgcGFnZVNjYWxlRmFjdG9yIGludG8gYWNjb3VudCBmb3IgTW91c2VSZWxhdGVkRXZlbnRz LgpJbmRleDogTGF5b3V0VGVzdHMvc3ZnL2FuaW1hdGlvbnMvYW5pbWF0ZS1wYXRoLW5lc3RlZC10 cmFuc2Zvcm1zLWV4cGVjdGVkLnR4dAo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBMYXlvdXRUZXN0cy9zdmcvYW5p bWF0aW9ucy9hbmltYXRlLXBhdGgtbmVzdGVkLXRyYW5zZm9ybXMtZXhwZWN0ZWQudHh0CShyZXZp c2lvbiA5NDQ5MikKKysrIExheW91dFRlc3RzL3N2Zy9hbmltYXRpb25zL2FuaW1hdGUtcGF0aC1u ZXN0ZWQtdHJhbnNmb3Jtcy1leHBlY3RlZC50eHQJKHdvcmtpbmcgY29weSkKQEAgLTUsMTAgKzUs MTAgQEAgdGVzdCB0byBkZXRlcm1pbmUgd2hldGhlciBhdXRvLXJvdGF0ZSBhbgogT24gc3VjY2Vz cywgeW91IHdpbGwgc2VlIGEgc2VyaWVzIG9mICJQQVNTIiBtZXNzYWdlcywgZm9sbG93ZWQgYnkg IlRFU1QgQ09NUExFVEUiLgogCiAKLVBBU1Mgcm9vdFNWR0VsZW1lbnQuZ2V0QkJveCgpLnggaXMg YWxtb3N0IDQwMCAod2l0aGluIDIwKQotUEFTUyByb290U1ZHRWxlbWVudC5nZXRCQm94KCkueSBp cyBhbG1vc3QgMjQwICh3aXRoaW4gMjApCi1QQVNTIHJvb3RTVkdFbGVtZW50LmdldEJCb3goKS54 IGlzIGFsbW9zdCA2NjAgKHdpdGhpbiAyMCkKLVBBU1Mgcm9vdFNWR0VsZW1lbnQuZ2V0QkJveCgp LnkgaXMgYWxtb3N0IDI3MCAod2l0aGluIDIwKQorUEFTUyByb290U1ZHRWxlbWVudC5nZXRCQm94 KCkueCBpcyBhbG1vc3QgMTMyICh3aXRoaW4gMjApCitQQVNTIHJvb3RTVkdFbGVtZW50LmdldEJC b3goKS55IGlzIGFsbW9zdCAtOTAgKHdpdGhpbiAyMCkKK1BBU1Mgcm9vdFNWR0VsZW1lbnQuZ2V0 QkJveCgpLnggaXMgYWxtb3N0IDMzMiAod2l0aGluIDIwKQorUEFTUyByb290U1ZHRWxlbWVudC5n ZXRCQm94KCkueSBpcyBhbG1vc3QgNTUwICh3aXRoaW4gMjApCiBQQVNTIHN1Y2Nlc3NmdWxseVBh cnNlZCBpcyB0cnVlCiAKIFRFU1QgQ09NUExFVEUKSW5kZXg6IExheW91dFRlc3RzL3N2Zy9hbmlt YXRpb25zL2FuaW1hdGUtdGV4dC1uZXN0ZWQtdHJhbnNmb3Jtcy1leHBlY3RlZC50eHQKPT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PQotLS0gTGF5b3V0VGVzdHMvc3ZnL2FuaW1hdGlvbnMvYW5pbWF0ZS10ZXh0LW5lc3RlZC10 cmFuc2Zvcm1zLWV4cGVjdGVkLnR4dAkocmV2aXNpb24gOTQ0OTIpCisrKyBMYXlvdXRUZXN0cy9z dmcvYW5pbWF0aW9ucy9hbmltYXRlLXRleHQtbmVzdGVkLXRyYW5zZm9ybXMtZXhwZWN0ZWQudHh0 CSh3b3JraW5nIGNvcHkpCkBAIC02LDEwICs2LDEwIEBAIHRlc3QgdG8gZGV0ZXJtaW5lIHdoZXRo ZXIgYXV0by1yb3RhdGUgYW4KIE9uIHN1Y2Nlc3MsIHlvdSB3aWxsIHNlZSBhIHNlcmllcyBvZiAi UEFTUyIgbWVzc2FnZXMsIGZvbGxvd2VkIGJ5ICJURVNUIENPTVBMRVRFIi4KIAogCi1QQVNTIHJv b3RTVkdFbGVtZW50LmdldEJCb3goKS54IGlzIGFsbW9zdCAzOTAgKHdpdGhpbiAyMCkKLVBBU1Mg cm9vdFNWR0VsZW1lbnQuZ2V0QkJveCgpLnkgaXMgYWxtb3N0IDE0MCAod2l0aGluIDIwKQotUEFT UyByb290U1ZHRWxlbWVudC5nZXRCQm94KCkueCBpcyBhbG1vc3QgNzAwICh3aXRoaW4gMjApCi1Q QVNTIHJvb3RTVkdFbGVtZW50LmdldEJCb3goKS55IGlzIGFsbW9zdCAyNzAgKHdpdGhpbiAyMCkK K1BBU1Mgcm9vdFNWR0VsZW1lbnQuZ2V0QkJveCgpLnggaXMgYWxtb3N0IDE5NiAod2l0aGluIDIw KQorUEFTUyByb290U1ZHRWxlbWVudC5nZXRCQm94KCkueSBpcyBhbG1vc3QgLTE4NiAod2l0aGlu IDIwKQorUEFTUyByb290U1ZHRWxlbWVudC5nZXRCQm94KCkueCBpcyBhbG1vc3QgMzcwICh3aXRo aW4gMjApCitQQVNTIHJvb3RTVkdFbGVtZW50LmdldEJCb3goKS55IGlzIGFsbW9zdCA1NDcgKHdp dGhpbiAyMCkKIFBBU1Mgc3VjY2Vzc2Z1bGx5UGFyc2VkIGlzIHRydWUKIAogVEVTVCBDT01QTEVU RQpJbmRleDogTGF5b3V0VGVzdHMvc3ZnL2FuaW1hdGlvbnMvc3ZndHJhbnNmb3JtLWFuaW1hdGlv bi1kaXNjcmV0ZS1leHBlY3RlZC50eHQKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gTGF5b3V0VGVzdHMvc3ZnL2Fu aW1hdGlvbnMvc3ZndHJhbnNmb3JtLWFuaW1hdGlvbi1kaXNjcmV0ZS1leHBlY3RlZC50eHQJKHJl dmlzaW9uIDk0NDkyKQorKysgTGF5b3V0VGVzdHMvc3ZnL2FuaW1hdGlvbnMvc3ZndHJhbnNmb3Jt LWFuaW1hdGlvbi1kaXNjcmV0ZS1leHBlY3RlZC50eHQJKHdvcmtpbmcgY29weSkKQEAgLTEsNCAr MSw0IEBACi1TVkcgMS4xIHRyYW5zZm9ybSBhbmltYXRpb24gdGVzdHMKK1NWRyAxLjEgZHluYW1p YyBhbmltYXRpb24gdGVzdHMKIAogVGVzdCBjYWxjTW9kZT1kaXNjcmV0ZSBhbmltYXRpb24gb24g U1ZHQW5pbWF0ZVRyYW5zZm9ybS4KIApJbmRleDogTGF5b3V0VGVzdHMvc3ZnL2FuaW1hdGlvbnMv c3ZndHJhbnNmb3JtLWFuaW1hdGlvbi1kaXNjcmV0ZS5odG1sCj09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIExheW91 dFRlc3RzL3N2Zy9hbmltYXRpb25zL3N2Z3RyYW5zZm9ybS1hbmltYXRpb24tZGlzY3JldGUuaHRt bAkocmV2aXNpb24gOTQ0OTIpCisrKyBMYXlvdXRUZXN0cy9zdmcvYW5pbWF0aW9ucy9zdmd0cmFu c2Zvcm0tYW5pbWF0aW9uLWRpc2NyZXRlLmh0bWwJKHdvcmtpbmcgY29weSkKQEAgLTcsNyArNyw3 IEBACiA8c2NyaXB0IHNyYz0icmVzb3VyY2VzL1NWR0FuaW1hdGlvblRlc3RDYXNlLmpzIj48L3Nj cmlwdD4KIDwvaGVhZD4KIDxib2R5PgotPGgxPlNWRyAxLjEgdHJhbnNmb3JtIGFuaW1hdGlvbiB0 ZXN0czwvaDE+Cis8aDE+U1ZHIDEuMSBkeW5hbWljIGFuaW1hdGlvbiB0ZXN0czwvaDE+CiA8cCBp ZD0iZGVzY3JpcHRpb24iPjwvcD4KIDxkaXYgaWQ9ImNvbnNvbGUiPjwvZGl2PgogPHNjcmlwdCBz cmM9InNjcmlwdC10ZXN0cy9zdmd0cmFuc2Zvcm0tYW5pbWF0aW9uLWRpc2NyZXRlLmpzIj48L3Nj cmlwdD4KSW5kZXg6IExheW91dFRlc3RzL3N2Zy9hbmltYXRpb25zL3NjcmlwdC10ZXN0cy9hbmlt YXRlLXBhdGgtbmVzdGVkLXRyYW5zZm9ybXMuanMKPT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gTGF5b3V0VGVzdHMv c3ZnL2FuaW1hdGlvbnMvc2NyaXB0LXRlc3RzL2FuaW1hdGUtcGF0aC1uZXN0ZWQtdHJhbnNmb3Jt cy5qcwkocmV2aXNpb24gOTQ0OTIpCisrKyBMYXlvdXRUZXN0cy9zdmcvYW5pbWF0aW9ucy9zY3Jp cHQtdGVzdHMvYW5pbWF0ZS1wYXRoLW5lc3RlZC10cmFuc2Zvcm1zLmpzCSh3b3JraW5nIGNvcHkp CkBAIC0zNSwxMyArMzUsMTMgQEAgZnVuY3Rpb24gcGFzc0lmQ2xvc2VFbm91Z2gobmFtZSwgdmFs dWUsIAogfQogCiBmdW5jdGlvbiBzdGFydFNhbXBsZSgpIHsKLSAgICBwYXNzSWZDbG9zZUVub3Vn aCgicm9vdFNWR0VsZW1lbnQuZ2V0QkJveCgpLngiLCA0MDAsIDIwKTsKLSAgICBwYXNzSWZDbG9z ZUVub3VnaCgicm9vdFNWR0VsZW1lbnQuZ2V0QkJveCgpLnkiLCAyNDAsIDIwKTsKKyAgICBwYXNz SWZDbG9zZUVub3VnaCgicm9vdFNWR0VsZW1lbnQuZ2V0QkJveCgpLngiLCAxMzIsIDIwKTsKKyAg ICBwYXNzSWZDbG9zZUVub3VnaCgicm9vdFNWR0VsZW1lbnQuZ2V0QkJveCgpLnkiLCAtOTAsIDIw KTsKIH0KIAogZnVuY3Rpb24gZW5kU2FtcGxlKCkgewotICAgIHBhc3NJZkNsb3NlRW5vdWdoKCJy b290U1ZHRWxlbWVudC5nZXRCQm94KCkueCIsIDY2MCwgMjApOwotICAgIHBhc3NJZkNsb3NlRW5v dWdoKCJyb290U1ZHRWxlbWVudC5nZXRCQm94KCkueSIsIDI3MCwgMjApOworICAgIHBhc3NJZkNs b3NlRW5vdWdoKCJyb290U1ZHRWxlbWVudC5nZXRCQm94KCkueCIsIDMzMiwgMjApOworICAgIHBh c3NJZkNsb3NlRW5vdWdoKCJyb290U1ZHRWxlbWVudC5nZXRCQm94KCkueSIsIDU1MCwgMjApOwog fQogCiBmdW5jdGlvbiBleGVjdXRlVGVzdCgpIHsKSW5kZXg6IExheW91dFRlc3RzL3N2Zy9hbmlt YXRpb25zL3NjcmlwdC10ZXN0cy9hbmltYXRlLXRleHQtbmVzdGVkLXRyYW5zZm9ybXMuanMKPT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PQotLS0gTGF5b3V0VGVzdHMvc3ZnL2FuaW1hdGlvbnMvc2NyaXB0LXRlc3RzL2FuaW1h dGUtdGV4dC1uZXN0ZWQtdHJhbnNmb3Jtcy5qcwkocmV2aXNpb24gOTQ0OTIpCisrKyBMYXlvdXRU ZXN0cy9zdmcvYW5pbWF0aW9ucy9zY3JpcHQtdGVzdHMvYW5pbWF0ZS10ZXh0LW5lc3RlZC10cmFu c2Zvcm1zLmpzCSh3b3JraW5nIGNvcHkpCkBAIC0yOCwxMyArMjgsMTMgQEAgZnVuY3Rpb24gcGFz c0lmQ2xvc2VFbm91Z2gobmFtZSwgdmFsdWUsIAogfQogCiBmdW5jdGlvbiBzdGFydFNhbXBsZSgp IHsKLSAgICBwYXNzSWZDbG9zZUVub3VnaCgicm9vdFNWR0VsZW1lbnQuZ2V0QkJveCgpLngiLCAz OTAsIDIwKTsKLSAgICBwYXNzSWZDbG9zZUVub3VnaCgicm9vdFNWR0VsZW1lbnQuZ2V0QkJveCgp LnkiLCAxNDAsIDIwKTsKKyAgICBwYXNzSWZDbG9zZUVub3VnaCgicm9vdFNWR0VsZW1lbnQuZ2V0 QkJveCgpLngiLCAxOTYsIDIwKTsKKyAgICBwYXNzSWZDbG9zZUVub3VnaCgicm9vdFNWR0VsZW1l bnQuZ2V0QkJveCgpLnkiLCAtMTg2LCAyMCk7CiB9CiAKIGZ1bmN0aW9uIGVuZFNhbXBsZSgpIHsK LSAgICBwYXNzSWZDbG9zZUVub3VnaCgicm9vdFNWR0VsZW1lbnQuZ2V0QkJveCgpLngiLCA3MDAs IDIwKTsKLSAgICBwYXNzSWZDbG9zZUVub3VnaCgicm9vdFNWR0VsZW1lbnQuZ2V0QkJveCgpLnki LCAyNzAsIDIwKTsKKyAgICBwYXNzSWZDbG9zZUVub3VnaCgicm9vdFNWR0VsZW1lbnQuZ2V0QkJv eCgpLngiLCAzNzAsIDIwKTsKKyAgICBwYXNzSWZDbG9zZUVub3VnaCgicm9vdFNWR0VsZW1lbnQu Z2V0QkJveCgpLnkiLCA1NDcsIDIwKTsKIH0KIAogZnVuY3Rpb24gZXhlY3V0ZVRlc3QoKSB7Cg==