65274 2011-07-27 12:26:32 -0700 Different elapsed times used during update of animation 2019-09-02 02:39:10 -0700 1 1 1 Unclassified WebKit SVG 528+ (Nightly build) Unspecified Unspecified RESOLVED FIXED P2 Normal --- 41761 0 scottmg scottmg abecsi eric jamesr koivisto krit simon.fraser zimmermann oldest_to_newest 443083 0 scottmg 2011-07-27 12:26:32 -0700 In some places during SMILTimeContainer and SVGSMILElement, the elapsed time from the fired timer is used to update animations, and in others, elapsed() is recalled. This eventually recalls the client's currentTime() so the animation will be updated with disparate times. Some more information: https://lists.webkit.org/pipermail/webkit-dev/2011-July/017649.html 443181 1 102192 scottmg 2011-07-27 15:16:13 -0700 Created attachment 102192 use one consistent elapsed time for animation update 443241 2 simon.fraser 2011-07-27 17:52:31 -0700 I wonder if we should plug in the same timebase that requestAnimationFrame etc use? Maybe not in this patch, but soon. 443264 3 jamesr 2011-07-27 18:35:10 -0700 Yeah, I'd really like to tie in the timebase and the scheduling for this in with requestAnimationFrame. That would mean changing the 'current time' notion from something internal to SMILTimeContainer to something passed in from the outside on each animation update. I also think it's a good thing for a different patch than this one. I'm not super familiar with SMIL but doesn't it allow applying transformations in time space (for example, making a container in which time travels twice as fast)? Is that handled at this level or somewhere else? 443308 4 scottmg 2011-07-27 21:07:26 -0700 I've only just started cozying up with the spec, so I'm not entirely sure if there's sub time warping requirements or not. FWIW, there's a comment in the time interval calculations claiming: // No nested time containers in SVG, no need for crazy time space conversions. Phew! but will need to investigate more for a future requestAnimationFrame patch. Is there anyone else who should review this patch as is? 443376 5 krit 2011-07-28 00:04:28 -0700 (In reply to comment #3) > Yeah, I'd really like to tie in the timebase and the scheduling for this in with requestAnimationFrame. That would mean changing the 'current time' notion from something internal to SMILTimeContainer to something passed in from the outside on each animation update. I also think it's a good thing for a different patch than this one. SVG has a time container per SVGSVGElement. And every time container can be paused and continued independent of the other time container. You can set the time of every container independent of the other containers. So we can end up with different time containers with different status per document. We could still use a global timer. But this needs to get considered. > > I'm not super familiar with SMIL but doesn't it allow applying transformations in time space (for example, making a container in which time travels twice as fast)? Is that handled at this level or somewhere else? Not sure if SMIL supports that, but SVG Animation doesn't. And we do not need a complete SMIL implementation. 524009 6 102192 eric 2011-12-19 10:51:26 -0800 Comment on attachment 102192 use one consistent elapsed time for animation update View in context: https://bugs.webkit.org/attachment.cgi?id=102192&action=review > Source/WebCore/ChangeLog:13 > + No new tests, but existing svg animations should continue to work > + correctly, and elapsed() is stable when stepping in debugger. Is this observable from the web? Can we test this? 524187 7 scottmg 2011-12-19 14:16:24 -0800 (In reply to comment #6) > (From update of attachment 102192 [details]) > View in context: https://bugs.webkit.org/attachment.cgi?id=102192&action=review > > > Source/WebCore/ChangeLog:13 > > + No new tests, but existing svg animations should continue to work > > + correctly, and elapsed() is stable when stepping in debugger. > > Is this observable from the web? Can we test this? I guess it would be on a heavily loaded machine. I can't think of good way to test automatically in a layout test though. My primary concern was really debugger single-stepping, but it just seemed wrong to update parts of the same animation with different times. 525406 8 102192 eric 2011-12-21 11:48:26 -0800 Comment on attachment 102192 use one consistent elapsed time for animation update Without some way to tst this, I'm sure this will break again. :( The change seems OK to me though. We do this all on the main thread (including running JavaScript) so there is no way this is observable from the web. Unless there are JS events which are fired synchronously from animations? But I doubt that. I'm not sure this change is worth it, for just debugging. 1567170 9 zimmermann 2019-09-02 02:39:10 -0700 This is fixed since r158405, by properly reporting a fixed time, if the animation is paused on a SMILTimeContainer. 102192 2011-07-27 15:16:13 -0700 2011-12-21 11:48:26 -0800 use one consistent elapsed time for animation update bug-65274-20110727151612.patch text/plain 3401 scottmg U3VidmVyc2lvbiBSZXZpc2lvbjogOTE4NjQKZGlmZiAtLWdpdCBhL1NvdXJjZS9XZWJDb3JlL0No YW5nZUxvZyBiL1NvdXJjZS9XZWJDb3JlL0NoYW5nZUxvZwppbmRleCAxOTYyNGY3N2U0NmY3MDI5 YjI0YmJjNDRhZTA4OGIyMGUxZWVhNTQ5Li5kNzFiODQyYzE5YjVhYTc2NjY0NDY4MTZhYzY2YjA2 MWRhNzc1MzYxIDEwMDY0NAotLS0gYS9Tb3VyY2UvV2ViQ29yZS9DaGFuZ2VMb2cKKysrIGIvU291 cmNlL1dlYkNvcmUvQ2hhbmdlTG9nCkBAIC0xLDMgKzEsMjMgQEAKKzIwMTEtMDctMjcgIFNjb3R0 IEdyYWhhbSAgPHNjb3R0bWdAZ29vZ2xlLmNvbT4KKworICAgICAgICBEaWZmZXJlbnQgZWxhcHNl ZCB0aW1lcyB1c2VkIGR1cmluZyB1cGRhdGUgb2YgYW5pbWF0aW9uCisgICAgICAgIGh0dHBzOi8v YnVncy53ZWJraXQub3JnL3Nob3dfYnVnLmNnaT9pZD02NTI3NAorCisgICAgICAgIFJldmlld2Vk IGJ5IE5PQk9EWSAoT09QUyEpLgorCisgICAgICAgIFdoZW4gdXBkYXRpbmcgYW5pbWF0aW9ucywg c2F2ZSBhbmQgdXNlIHRoZSBlbGFwc2VkIHRpbWUgYXMKKyAgICAgICAgbV9lbGFwc2VkRm9yQW5p bWF0aW9uVXBkYXRlIHNvIHRoYXQgYWxsIGFuaW1hdGlvbnMgYXJlIHVwZGF0ZWQKKyAgICAgICAg Y29uc2lzdGVudGx5IHJhdGhlciB0aGFuIHJlc2FtcGxpbmcgdGhlIGNsb2NrIHJlcGVhdGVkbHku CisKKyAgICAgICAgTm8gbmV3IHRlc3RzLCBidXQgZXhpc3Rpbmcgc3ZnIGFuaW1hdGlvbnMgc2hv dWxkIGNvbnRpbnVlIHRvIHdvcmsKKyAgICAgICAgY29ycmVjdGx5LCBhbmQgZWxhcHNlZCgpIGlz IHN0YWJsZSB3aGVuIHN0ZXBwaW5nIGluIGRlYnVnZ2VyLgorCisgICAgICAgICogc3ZnL2FuaW1h dGlvbi9TTUlMVGltZUNvbnRhaW5lci5jcHA6CisgICAgICAgIChXZWJDb3JlOjpTTUlMVGltZUNv bnRhaW5lcjo6U01JTFRpbWVDb250YWluZXIpOgorICAgICAgICAoV2ViQ29yZTo6U01JTFRpbWVD b250YWluZXI6OmVsYXBzZWQpOgorICAgICAgICAoV2ViQ29yZTo6U01JTFRpbWVDb250YWluZXI6 OnVwZGF0ZUFuaW1hdGlvbnMpOgorICAgICAgICAqIHN2Zy9hbmltYXRpb24vU01JTFRpbWVDb250 YWluZXIuaDoKKwogMjAxMS0wNy0yNSAgTWloYWkgUGFycGFyaXRhICA8bWloYWlwQGNocm9taXVt Lm9yZz4KIAogICAgICAgICBbQ2hyb21pdW1dIEFkZCBiZXR0ZXIgV2ViS2l0IEFQSSBmb3IgY2hy b21lLnRhYnMuaW5zZXJ0Q1NTIGV4dGVuc2lvbiBBUEkKZGlmZiAtLWdpdCBhL1NvdXJjZS9XZWJD b3JlL3N2Zy9hbmltYXRpb24vU01JTFRpbWVDb250YWluZXIuY3BwIGIvU291cmNlL1dlYkNvcmUv c3ZnL2FuaW1hdGlvbi9TTUlMVGltZUNvbnRhaW5lci5jcHAKaW5kZXggZTliYjM4YWViMTA0ZTI0 MDY0ZmMxYWQ4ODI4ODNlYTZmN2UxNDkwOS4uYzRkOTM2NzdmZTBjNzZiYWNkYWY5ZGQyNGRlMTZm NTBlNWEyMmEyOCAxMDA2NDQKLS0tIGEvU291cmNlL1dlYkNvcmUvc3ZnL2FuaW1hdGlvbi9TTUlM VGltZUNvbnRhaW5lci5jcHAKKysrIGIvU291cmNlL1dlYkNvcmUvc3ZnL2FuaW1hdGlvbi9TTUlM VGltZUNvbnRhaW5lci5jcHAKQEAgLTQ2LDYgKzQ2LDcgQEAgU01JTFRpbWVDb250YWluZXI6OlNN SUxUaW1lQ29udGFpbmVyKFNWR1NWR0VsZW1lbnQqIG93bmVyKQogICAgIDogbV9iZWdpblRpbWUo MCkKICAgICAsIG1fcGF1c2VUaW1lKDApCiAgICAgLCBtX2FjY3VtdWxhdGVkUGF1c2VUaW1lKDAp CisgICAgLCBtX2VsYXBzZWRGb3JBbmltYXRpb25VcGRhdGUoLTEpCiAgICAgLCBtX2RvY3VtZW50 T3JkZXJJbmRleGVzRGlydHkoZmFsc2UpCiAgICAgLCBtX3RpbWVyKHRoaXMsICZTTUlMVGltZUNv bnRhaW5lcjo6dGltZXJGaXJlZCkKICAgICAsIG1fb3duZXJTVkdFbGVtZW50KG93bmVyKQpAQCAt ODIsNiArODMsMTAgQEAgU01JTFRpbWUgU01JTFRpbWVDb250YWluZXI6OmVsYXBzZWQoKSBjb25z dAogewogICAgIGlmICghbV9iZWdpblRpbWUpCiAgICAgICAgIHJldHVybiAwOworCisgICAgaWYg KG1fZWxhcHNlZEZvckFuaW1hdGlvblVwZGF0ZSA+PSAwLjApCisgICAgICAgIHJldHVybiBtX2Vs YXBzZWRGb3JBbmltYXRpb25VcGRhdGU7CisKICAgICByZXR1cm4gY3VycmVudFRpbWUoKSAtIG1f YmVnaW5UaW1lIC0gbV9hY2N1bXVsYXRlZFBhdXNlVGltZTsKIH0KICAgICAKQEAgLTI0NCw2ICsy NDksOCBAQCB2b2lkIFNNSUxUaW1lQ29udGFpbmVyOjp1cGRhdGVBbmltYXRpb25zKFNNSUxUaW1l IGVsYXBzZWQsIGRvdWJsZSBuZXh0TWFudWFsU2FtcAogICAgICAgICBlbGFwc2VkID0gU01JTFRp bWUobmV4dE1hbnVhbFNhbXBsZVRpbWUpICsgc2FtcGxpbmdEaWZmOwogICAgIH0KIAorICAgIG1f ZWxhcHNlZEZvckFuaW1hdGlvblVwZGF0ZSA9IGVsYXBzZWQudmFsdWUoKTsKKwogICAgIC8vIFNv cnQgYWNjb3JkaW5nIHRvIHByaW9yaXR5LiBFbGVtZW50cyB3aXRoIGxhdGVyIGJlZ2luIHRpbWUg aGF2ZSBoaWdoZXIgcHJpb3JpdHkuCiAgICAgLy8gSW4gY2FzZSBvZiBhIHRpZSwgZG9jdW1lbnQg b3JkZXIgZGVjaWRlcy4gCiAgICAgLy8gRklYTUU6IFRoaXMgc2hvdWxkIGFsc28gY29uc2lkZXIg dGltaW5nIHJlbGF0aW9uc2hpcHMgYmV0d2VlbiB0aGUgZWxlbWVudHMuIERlcGVuZGVudHMKQEAg LTMwOSw2ICszMTYsOCBAQCB2b2lkIFNNSUxUaW1lQ29udGFpbmVyOjp1cGRhdGVBbmltYXRpb25z KFNNSUxUaW1lIGVsYXBzZWQsIGRvdWJsZSBuZXh0TWFudWFsU2FtcAogICAgIHN0YXJ0VGltZXIo ZWFybGllcnNGaXJlVGltZSwgYW5pbWF0aW9uRnJhbWVEZWxheSk7CiAgICAgCiAgICAgRG9jdW1l bnQ6OnVwZGF0ZVN0eWxlRm9yQWxsRG9jdW1lbnRzKCk7CisKKyAgICBtX2VsYXBzZWRGb3JBbmlt YXRpb25VcGRhdGUgPSAtMTsKIH0KIAogI2VuZGlmCmRpZmYgLS1naXQgYS9Tb3VyY2UvV2ViQ29y ZS9zdmcvYW5pbWF0aW9uL1NNSUxUaW1lQ29udGFpbmVyLmggYi9Tb3VyY2UvV2ViQ29yZS9zdmcv YW5pbWF0aW9uL1NNSUxUaW1lQ29udGFpbmVyLmgKaW5kZXggNzAwODUwOGYyZTlmZGYyMDdkMmQx NzA1MzcyNWNlY2ExYzI1NGRkNi4uYmFiZjNkNmExZmFiZDRiNWYxYWNmYzI0NDM3MjA5OTEyZGQw OWRhNyAxMDA2NDQKLS0tIGEvU291cmNlL1dlYkNvcmUvc3ZnL2FuaW1hdGlvbi9TTUlMVGltZUNv bnRhaW5lci5oCisrKyBiL1NvdXJjZS9XZWJDb3JlL3N2Zy9hbmltYXRpb24vU01JTFRpbWVDb250 YWluZXIuaApAQCAtODEsNiArODEsNyBAQCBwcml2YXRlOgogICAgIGRvdWJsZSBtX2JlZ2luVGlt ZTsKICAgICBkb3VibGUgbV9wYXVzZVRpbWU7CiAgICAgZG91YmxlIG1fYWNjdW11bGF0ZWRQYXVz ZVRpbWU7CisgICAgZG91YmxlIG1fZWxhcHNlZEZvckFuaW1hdGlvblVwZGF0ZTsKIAogICAgIGJv b2wgbV9kb2N1bWVudE9yZGVySW5kZXhlc0RpcnR5OwogICAgIAo=