35115 2010-02-18 11:03:09 -0800 REGRESSION: r54919 can cause image animation to start late 2010-02-24 13:52:28 -0800 1 1 1 Unclassified WebKit Images 528+ (Nightly build) PC All RESOLVED FIXED P2 Normal --- 35287 35065 1 pkasting pkasting mjs mrowe sam webkit.review.bot oldest_to_newest 191666 0 pkasting 2010-02-18 11:03:09 -0800 The patch on bug 35065 introduced this bug. Fix is easy. 191703 1 49035 pkasting 2010-02-18 12:56:08 -0800 Created attachment 49035 patch v1 191706 2 webkit.review.bot 2010-02-18 13:01:52 -0800 Attachment 49035 did not pass style-queue: Failed to run "WebKitTools/Scripts/check-webkit-style" exit_code: 1 WebCore/platform/graphics/BitmapImage.cpp:271: Tests for true/false, null/non-null, and zero/non-zero should all be done without equality comparisons. [readability/comparison_to_zero] [5] Total errors found: 1 in 2 files If any of these errors are false positives, please file a bug against check-webkit-style. 191707 3 49037 pkasting 2010-02-18 13:03:51 -0800 Created attachment 49037 patch v2 Fix style nit 192110 4 49037 abarth 2010-02-19 16:36:32 -0800 Comment on attachment 49037 patch v2 Are we not able to test image animation bugs? 192113 5 pkasting 2010-02-19 16:42:00 -0800 I have utterly no clue how to test this particular case. 192115 6 pkasting 2010-02-19 16:46:00 -0800 Fixed in r55039. 192323 7 mrowe 2010-02-21 16:42:17 -0800 I filed bug 35222 about a regression this introduced. 192401 8 mrowe 2010-02-22 03:19:37 -0800 Reopening as this was rolled out in r55076 to address bug 35222. 192570 9 pkasting 2010-02-22 12:54:01 -0800 Let me circle back and describe what's going on with all these bugs. Skipping frames during image load is possible when the network is bursty -- if you are given some data, then no data, then data for multiple frames at once, you can skip to the last available frame in one shot. The more common behavior is that data streams in slowly and you see each frame show up until we have the next one. In either case, we won't skip past the end -- when we load the image completely (and it finishes animating if necessary) we'll start animating from the beginning at the correct speed. The patch on this bug does not change this behavior. This behavior comes from the original set of timing fixes a couple of years ago. The patch on this bug merely preserves the behavior that we had before bug 35065 was fixed, where the timer starts from when we first ask the image to animate, rather than when we are able to advance to frame 2. This can make a visible change in the following scenario. The network gives us frame 1 of the animation, then hangs a long time, then provides most of the rest of the data all at once. The behaviors are: * Before bug 35065 landed: We would erroneously keep adding the frame 1 start time every time through this function, resulting in the image not animating at all for a long time during and after load, and then starting to animate smoothly. * After bug 35065 landed: We would erroneously fail to start the animation timer until frame 2 arrived, at which point we'd begin animating smoothly. * After this patch landed: We start the timer immediately, and when the rest of the data arrives, skip forward. HOWEVER, note the following similar case: if we get frames 1 _and 2_, then a pause, then the rest of the data, the behavior before and after this patch landed is identical, and corresponds to the third bullet above. What's really happening here is that the fix on bug 35065 eliminated a bunch of unintentional delays during the initial load and exposed the (designed) behavior that we can frameskip during initial load (although we usually don't). So this patch did not really "cause" bug 35222, although it made it possible to occur in one more frame's worth of cases. We can decide that we are OK with this behavior (better for sites that sync GIFs to each other or other page elements), in which case we should simply reland this patch and move on. Or we can decide that we'd like each frame to appear for at least its desired duration during load, in which case I can rewrite the timing code to accomplish this, which will probably equate to relanding this patch and adding some conditionals. 192658 10 mrowe 2010-02-22 15:10:07 -0800 Can you please provide a concrete example of the issue that you’re attempting to describe here? It’s much easier to discuss a concrete problem than a hypothetical issue. 192665 11 pkasting 2010-02-22 15:14:41 -0800 Which issue are you referring to? Comment 9 is applicable to any animated GIF, it is merely dependent on the network. (If possible I'd really like to discuss over IRC, I think it will be faster and easier than bugzilla) 192739 12 mrowe 2010-02-22 18:38:02 -0800 (In reply to comment #11) > Which issue are you referring to? Comment 9 is applicable to any animated GIF, > it is merely dependent on the network. > The issue that this bug was filed about. 192772 13 pkasting 2010-02-22 20:34:45 -0800 The issue that this was filed about can apply to any animated GIF, its magnitude is merely dependent on network performance. As I tried to say on bug 35065, the issue is that after the patch on that bug, we display the first frame until we have the complete second frame, and then start the first frame's animation timer. This means that the animation start lags by however long it takes us to get the second frame's data, which depends on the network. Note that the issue here is not about how we display frames in general as the image is loading -- as I tried to say in comment 9, that behavior, such as whether bursty networks can cause frameskipping during the initial load, is a more general issue. This bug was only about whether we start the animation timer when we receive frame 1 or when we receive frame 2, nothing more. Whatever decision we make about how the user should see frames during load, we want this patch or something similar. If the network is fast, it makes us display the animation with perfect timing, and if the network is slow and we want to modify the current display algorithm, we'd want to do it by ensuring we show each frame for its entire duration, not the behavior that this patch fixes (which is just a plain and simple bug). 192797 14 mrowe 2010-02-22 23:25:25 -0800 (In reply to comment #13) > The issue that this was filed about can apply to any animated GIF, its > magnitude is merely dependent on network performance. As I tried to say on bug > 35065, the issue is that after the patch on that bug, we display the first > frame until we have the complete second frame, and then start the first frame's > animation timer. This means that the animation start lags by however long it > takes us to get the second frame's data, which depends on the network. Note > that the issue here is not about how we display frames in general as the image > is loading -- as I tried to say in comment 9, that behavior, such as whether > bursty networks can cause frameskipping during the initial load, is a more > general issue. This bug was only about whether we start the animation timer > when we receive frame 1 or when we receive frame 2, nothing more. Ok, now I see what you’re saying. I have a concern here that is based on looking at the computed values for BitmapImage::frameIsCompleteAtIndex inside BitmapImage::startAnimation while loading some animated GIFs over a slow-ish network: frameIsCompleteAtIndex appears to always return false until the image has completely loaded. This happens even for frame 0 when the initial frame of the animation has already painted on-screen. This doesn’t seem to match the intended behavior of the function. > Whatever decision we make about how the user should see frames during load, we > want this patch or something similar. If the network is fast, it makes us > display the animation with perfect timing, and if the network is slow and we > want to modify the current display algorithm, we'd want to do it by ensuring we > show each frame for its entire duration, not the behavior that this patch fixes > (which is just a plain and simple bug). It is not clear to me what you mean by “modify the current display algorithm”. Are you talking about the algorithm as designed, or as it currently behaves? From my observations these seem to be two different things. It seems that the “as designed” behavior is that which I describe as being wrong in bug 35222: after painting the first frame the animation starts, and we drop any frames that aren’t loaded by the time they would have painted had the image been animating smoothly. Given the behavior of BitmapImage::frameIsCompleteAtIndex that I describe above, you can see that this results in no animation occurring while the image loads and then us immediately skipping many frames in the animation to catch up to where the animation would have been. The current behavior is different: after the second frame of the animation is available, the animation starts. Due to the behavior of BitmapImage::frameIsCompleteAtIndex always returning false until the image is completely loaded, this leads to the animation being paused until the image is completely loaded meaning that no frames will be dropped even when the network is slow. In the case that the image is already cached it presumably results in the initial frame being displayed for slightly longer than was intended. I suspect that if BitmapImage::frameIsCompleteAtIndex was behaving as expected that the only difference between the two behaviors would be that the second would lead to initial frame being displayed for longer than was intended (e.g., the original topic of this bug). If we fix the behavior of BitmapImage::frameIsCompleteAtIndex the original patch on this bug may then be what is needed. 192817 15 pkasting 2010-02-23 00:46:19 -0800 (In reply to comment #14) > I have a concern here that is based on > looking at the computed values for BitmapImage::frameIsCompleteAtIndex inside > BitmapImage::startAnimation while loading some animated GIFs over a slow-ish > network: frameIsCompleteAtIndex appears to always return false until the image > has completely loaded. This happens even for frame 0 when the initial frame of > the animation has already painted on-screen. This doesn’t seem to match the > intended behavior of the function. Yeah, that's not right at all. I suspect a CG-specific bug here; for CG this eventually boils down to the statement (in ImageSourceCG.cpp): CGImageSourceGetStatusAtIndex(m_decoder, index) == kCGImageStatusComplete It may be that this function is not returning "complete" for any index until the whole image is done, or perhaps it's just doing that for < Snow Leopard (since I know some GIF shouldn't-need-the-whole-image-but-we-do issues were supposed to be fixed in Snow Leopard). Seems like you could probably test this fairly quickly? I haven't tested closely, but based on the overall behavior I see and the code in them, I think the open-source decoders return the desired values for this function. This means that Safari and Chromium would see vastly different behavior here which would help explain why we've been talking past each other. I could be wrong and there's a bug in BitmapImage.cpp instead, but a quick inspection didn't highlight anything obvious and I've never seen the behavior you describe locally. > It seems that the “as designed” behavior is that which I describe as being > wrong in bug 35222: after painting the first frame the animation starts, and we > drop any frames that aren’t loaded by the time they would have painted had the > image been animating smoothly. With the caveat of "if we have frames beyond them to skip to", I think this is accurate. > Given the behavior of > BitmapImage::frameIsCompleteAtIndex that I describe above, you can see that > this results in no animation occurring while the image loads and then us > immediately skipping many frames in the animation to catch up to where the > animation would have been. Yes, that's obviously gruesomely bad. That turns what I described as a rare case into the common case, even for moderately fast networks. There is a small saving grace here, which is that if the load has taken longer than the entire length of the animation, the code (with the buggy frameIsCompleteAtIndex()) will start the animation at the beginning (of its second cycle, not that that's visible to the user), so on REALLY slow networks, this doesn't look as bad. But that's fairly irrelevant as we definitely want to fix this broken oracle function. > The current behavior is different: after the second frame of the animation is > available, the animation starts. Due to the behavior of > BitmapImage::frameIsCompleteAtIndex always returning false until the image is > completely loaded, this leads to the animation being paused until the image is > completely loaded meaning that no frames will be dropped even when the network > is slow. In the case that the image is already cached it presumably results in > the initial frame being displayed for slightly longer than was intended. That sounds accurate to me. > I suspect that if BitmapImage::frameIsCompleteAtIndex was behaving as expected > that the only difference between the two behaviors would be that the second > would lead to initial frame being displayed for longer than was intended (e.g., > the original topic of this bug). If we fix the behavior of > BitmapImage::frameIsCompleteAtIndex the original patch on this bug may then be > what is needed. Thanks for the great analysis. Fixing this function should certainly be the top priority, and it's nice to know why the seemingly-innocent patch on this bug could have caused such a large-seeming regression. Once we fix, then we should be back in the world described by comment 9, and can move forward. 192828 16 mrowe 2010-02-23 01:22:51 -0800 (In reply to comment #15) > (In reply to comment #14) > > I have a concern here that is based on > > looking at the computed values for BitmapImage::frameIsCompleteAtIndex inside > > BitmapImage::startAnimation while loading some animated GIFs over a slow-ish > > network: frameIsCompleteAtIndex appears to always return false until the image > > has completely loaded. This happens even for frame 0 when the initial frame of > > the animation has already painted on-screen. This doesn’t seem to match the > > intended behavior of the function. > > Yeah, that's not right at all. I suspect a CG-specific bug here; for CG this > eventually boils down to the statement (in ImageSourceCG.cpp): > > CGImageSourceGetStatusAtIndex(m_decoder, index) == kCGImageStatusComplete > > It may be that this function is not returning "complete" for any index until > the whole image is done, or perhaps it's just doing that for < Snow Leopard > (since I know some GIF shouldn't-need-the-whole-image-but-we-do issues were > supposed to be fixed in Snow Leopard). Seems like you could probably test this > fairly quickly? That’s basically the conclusion that I had arrived at too. It seems CGImageSourceGetStatusAtIndex claims that all frames of an animated GIF are incomplete when using an incremental image source that has not yet received the complete data of the image. This certainly isn’t the behavior that the author of ImageSource::frameIsCompleteAtIndex (or any reasonable person) expects. I’m not sure if this behavior changed from Leopard to SnowLeopard, but I filed a bug against CGImageSourceGetStatusAtIndex expressing my displeasure at the misleading results that it gives (<rdar://problem/7679174>). > I haven't tested closely, but based on the overall behavior I see and the code > in them, I think the open-source decoders return the desired values for this > function. This means that Safari and Chromium would see vastly different > behavior here which would help explain why we've been talking past each other. That would explain a lot! > Thanks for the great analysis. Fixing this function should certainly be the > top priority, and it's nice to know why the seemingly-innocent patch on this > bug could have caused such a large-seeming regression. Once we fix, then we > should be back in the world described by comment 9, and can move forward. I think I may have a solution for this. I’ll write up a bug about BitmapImage::frameIsCompleteAtIndex and will throw a patch up after some more testing. 192835 17 mrowe 2010-02-23 01:46:39 -0800 Bug for that issue is bug 35287. 193152 18 pkasting 2010-02-23 15:15:15 -0800 Now that bug 35287 is fixed (thanks!), should we re-land this? And then do you want to take a further look at how we should behave during image load, or do you think the current behavior is OK? 193210 19 mrowe 2010-02-23 18:14:14 -0800 (In reply to comment #18) > Now that bug 35287 is fixed (thanks!), should we re-land this? And then do you > want to take a further look at how we should behave during image load, or do > you think the current behavior is OK? Yes, I think it’s fine to land this change now. 193496 20 pkasting 2010-02-24 13:52:28 -0800 Fixed in r55199. 49035 2010-02-18 12:56:08 -0800 2010-02-18 13:03:51 -0800 patch v1 patch text/plain 3398 pkasting SW5kZXg6IFdlYkNvcmUvQ2hhbmdlTG9nCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIFdlYkNvcmUvQ2hhbmdlTG9n CShyZXZpc2lvbiA1NDk4MSkKKysrIFdlYkNvcmUvQ2hhbmdlTG9nCSh3b3JraW5nIGNvcHkpCkBA IC0xLDMgKzEsMTMgQEAKKzIwMTAtMDItMTggIFBldGVyIEthc3RpbmcgIDxwa2FzdGluZ0Bnb29n bGUuY29tPgorCisgICAgICAgIFJldmlld2VkIGJ5IE5PQk9EWSAoT09QUyEpLgorCisgICAgICAg IEZpeCByZWdyZXNzaW9uIGluIGNhbGN1bGF0aW5nIGFuIGFuaW1hdGVkIGltYWdlJ3Mgc3RhcnQg dGltZS4KKyAgICAgICAgaHR0cHM6Ly9idWdzLndlYmtpdC5vcmcvc2hvd19idWcuY2dpP2lkPTM1 MTE1CisKKyAgICAgICAgKiBwbGF0Zm9ybS9ncmFwaGljcy9CaXRtYXBJbWFnZS5jcHA6CisgICAg ICAgIChXZWJDb3JlOjpCaXRtYXBJbWFnZTo6c3RhcnRBbmltYXRpb24pOgorCiAyMDEwLTAyLTE3 ICBEdW1pdHJ1IERhbmlsaXVjICA8ZHVtaUBjaHJvbWl1bS5vcmc+CiAKICAgICAgICAgUmV2aWV3 ZWQgYnkgRGFyaW4gQWRsZXIuCkluZGV4OiBXZWJDb3JlL3BsYXRmb3JtL2dyYXBoaWNzL0JpdG1h cEltYWdlLmNwcAo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09Ci0tLSBXZWJDb3JlL3BsYXRmb3JtL2dyYXBoaWNzL0JpdG1h cEltYWdlLmNwcAkocmV2aXNpb24gNTQ5NzcpCisrKyBXZWJDb3JlL3BsYXRmb3JtL2dyYXBoaWNz L0JpdG1hcEltYWdlLmNwcAkod29ya2luZyBjb3B5KQpAQCAtMjY2LDYgKzI2NiwxMSBAQCB2b2lk IEJpdG1hcEltYWdlOjpzdGFydEFuaW1hdGlvbihib29sIGNhCiAgICAgaWYgKG1fZnJhbWVUaW1l ciB8fCAhc2hvdWxkQW5pbWF0ZSgpIHx8IGZyYW1lQ291bnQoKSA8PSAxKQogICAgICAgICByZXR1 cm47CiAKKyAgICAvLyBJZiB3ZSBhcmVuJ3QgYWxyZWFkeSBhbmltYXRpbmcsIHNldCBub3cgYXMg dGhlIGFuaW1hdGlvbiBzdGFydCB0aW1lLgorICAgIGNvbnN0IGRvdWJsZSB0aW1lID0gY3VycmVu dFRpbWUoKTsKKyAgICBpZiAobV9kZXNpcmVkRnJhbWVTdGFydFRpbWUgPT0gMCkKKyAgICAgICAg bV9kZXNpcmVkRnJhbWVTdGFydFRpbWUgPSB0aW1lOworCiAgICAgLy8gRG9uJ3QgYWR2YW5jZSB0 aGUgYW5pbWF0aW9uIHRvIGFuIGluY29tcGxldGUgZnJhbWUuCiAgICAgc2l6ZV90IG5leHRGcmFt ZSA9IChtX2N1cnJlbnRGcmFtZSArIDEpICUgZnJhbWVDb3VudCgpOwogICAgIGlmICghbV9hbGxE YXRhUmVjZWl2ZWQgJiYgIWZyYW1lSXNDb21wbGV0ZUF0SW5kZXgobmV4dEZyYW1lKSkKQEAgLTI4 MiwxOSArMjg3LDE0IEBAIHZvaWQgQml0bWFwSW1hZ2U6OnN0YXJ0QW5pbWF0aW9uKGJvb2wgY2EK ICAgICAvLyBpbiB0aGlzIGNhbGN1bGF0aW9uLCB3ZSBtYWtlIHRoZSBhbmltYXRpb24gYXBwZWFy IHRvIHJ1biBhdCBpdHMgZGVzaXJlZAogICAgIC8vIHJhdGUgcmVnYXJkbGVzcyBvZiBob3cgZmFz dCBpdCdzIGJlaW5nIHJlcGFpbnRlZC4KICAgICBjb25zdCBkb3VibGUgY3VycmVudER1cmF0aW9u ID0gZnJhbWVEdXJhdGlvbkF0SW5kZXgobV9jdXJyZW50RnJhbWUpOwotICAgIGNvbnN0IGRvdWJs ZSB0aW1lID0gY3VycmVudFRpbWUoKTsKLSAgICBpZiAobV9kZXNpcmVkRnJhbWVTdGFydFRpbWUg PT0gMCkgewotICAgICAgICBtX2Rlc2lyZWRGcmFtZVN0YXJ0VGltZSA9IHRpbWUgKyBjdXJyZW50 RHVyYXRpb247Ci0gICAgfSBlbHNlIHsKLSAgICAgICAgbV9kZXNpcmVkRnJhbWVTdGFydFRpbWUg Kz0gY3VycmVudER1cmF0aW9uOworICAgIG1fZGVzaXJlZEZyYW1lU3RhcnRUaW1lICs9IGN1cnJl bnREdXJhdGlvbjsKIAotICAgICAgICAvLyBXaGVuIGFuIGFuaW1hdGVkIGltYWdlIGlzIG1vcmUg dGhhbiBmaXZlIG1pbnV0ZXMgb3V0IG9mIGRhdGUsIHRoZQotICAgICAgICAvLyB1c2VyIHByb2Jh Ymx5IGRvZXNuJ3QgY2FyZSBhYm91dCByZXN5bmNpbmcgYW5kIHdlIGNvdWxkIGJ1cm4gYSBsb3Qg b2YKLSAgICAgICAgLy8gdGltZSBsb29waW5nIHRocm91Z2ggZnJhbWVzIGJlbG93LiAgSnVzdCBy ZXNldCB0aGUgdGltaW5ncy4KLSAgICAgICAgY29uc3QgZG91YmxlIGNBbmltYXRpb25SZXN5bmND dXRvZmYgPSA1ICogNjA7Ci0gICAgICAgIGlmICgodGltZSAtIG1fZGVzaXJlZEZyYW1lU3RhcnRU aW1lKSA+IGNBbmltYXRpb25SZXN5bmNDdXRvZmYpCi0gICAgICAgICAgICBtX2Rlc2lyZWRGcmFt ZVN0YXJ0VGltZSA9IHRpbWUgKyBjdXJyZW50RHVyYXRpb247Ci0gICAgfQorICAgIC8vIFdoZW4g YW4gYW5pbWF0ZWQgaW1hZ2UgaXMgbW9yZSB0aGFuIGZpdmUgbWludXRlcyBvdXQgb2YgZGF0ZSwg dGhlCisgICAgLy8gdXNlciBwcm9iYWJseSBkb2Vzbid0IGNhcmUgYWJvdXQgcmVzeW5jaW5nIGFu ZCB3ZSBjb3VsZCBidXJuIGEgbG90IG9mCisgICAgLy8gdGltZSBsb29waW5nIHRocm91Z2ggZnJh bWVzIGJlbG93LiAgSnVzdCByZXNldCB0aGUgdGltaW5ncy4KKyAgICBjb25zdCBkb3VibGUgY0Fu aW1hdGlvblJlc3luY0N1dG9mZiA9IDUgKiA2MDsKKyAgICBpZiAoKHRpbWUgLSBtX2Rlc2lyZWRG cmFtZVN0YXJ0VGltZSkgPiBjQW5pbWF0aW9uUmVzeW5jQ3V0b2ZmKQorICAgICAgICBtX2Rlc2ly ZWRGcmFtZVN0YXJ0VGltZSA9IHRpbWUgKyBjdXJyZW50RHVyYXRpb247CiAKICAgICAvLyBUaGUg aW1hZ2UgbWF5IGxvYWQgbW9yZSBzbG93bHkgdGhhbiBpdCdzIHN1cHBvc2VkIHRvIGFuaW1hdGUs IHNvIHRoYXQgYnkKICAgICAvLyB0aGUgdGltZSB3ZSByZWFjaCB0aGUgZW5kIG9mIHRoZSBmaXJz dCByZXBldGl0aW9uLCB3ZSdyZSB3ZWxsIGJlaGluZC4KQEAgLTMwNyw3ICszMDcsNyBAQCB2b2lk IEJpdG1hcEltYWdlOjpzdGFydEFuaW1hdGlvbihib29sIGNhCiAgICAgLy8gc3dpdGNoIHRhYnMg KGFuZCB0aHVzIHN0b3AgZHJhd2luZyB0aGUgYW5pbWF0aW9uLCB3aGljaCB3aWxsIHBhdXNlIGl0 KQogICAgIC8vIGR1cmluZyB0aGF0IGluaXRpYWwgbG9vcCwgdGhlbiBzd2l0Y2ggYmFjayBsYXRl ci4KICAgICBpZiAobmV4dEZyYW1lID09IDAgJiYgbV9yZXBldGl0aW9uc0NvbXBsZXRlID09IDAg JiYgbV9kZXNpcmVkRnJhbWVTdGFydFRpbWUgPCB0aW1lKQotICAgICAgbV9kZXNpcmVkRnJhbWVT dGFydFRpbWUgPSB0aW1lOworICAgICAgICBtX2Rlc2lyZWRGcmFtZVN0YXJ0VGltZSA9IHRpbWU7 CiAKICAgICBpZiAoIWNhdGNoVXBJZk5lY2Vzc2FyeSB8fCB0aW1lIDwgbV9kZXNpcmVkRnJhbWVT dGFydFRpbWUpIHsKICAgICAgICAgLy8gSGF2ZW4ndCB5ZXQgcmVhY2hlZCB0aW1lIGZvciBuZXh0 IGZyYW1lIHRvIHN0YXJ0OyBkZWxheSB1bnRpbCB0aGVuLgo= 49037 2010-02-18 13:03:51 -0800 2010-02-19 16:36:31 -0800 patch v2 patch text/plain 3394 pkasting SW5kZXg6IFdlYkNvcmUvQ2hhbmdlTG9nCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIFdlYkNvcmUvQ2hhbmdlTG9n CShyZXZpc2lvbiA1NDk4MSkKKysrIFdlYkNvcmUvQ2hhbmdlTG9nCSh3b3JraW5nIGNvcHkpCkBA IC0xLDMgKzEsMTMgQEAKKzIwMTAtMDItMTggIFBldGVyIEthc3RpbmcgIDxwa2FzdGluZ0Bnb29n bGUuY29tPgorCisgICAgICAgIFJldmlld2VkIGJ5IE5PQk9EWSAoT09QUyEpLgorCisgICAgICAg IEZpeCByZWdyZXNzaW9uIGluIGNhbGN1bGF0aW5nIGFuIGFuaW1hdGVkIGltYWdlJ3Mgc3RhcnQg dGltZS4KKyAgICAgICAgaHR0cHM6Ly9idWdzLndlYmtpdC5vcmcvc2hvd19idWcuY2dpP2lkPTM1 MTE1CisKKyAgICAgICAgKiBwbGF0Zm9ybS9ncmFwaGljcy9CaXRtYXBJbWFnZS5jcHA6CisgICAg ICAgIChXZWJDb3JlOjpCaXRtYXBJbWFnZTo6c3RhcnRBbmltYXRpb24pOgorCiAyMDEwLTAyLTE3 ICBEdW1pdHJ1IERhbmlsaXVjICA8ZHVtaUBjaHJvbWl1bS5vcmc+CiAKICAgICAgICAgUmV2aWV3 ZWQgYnkgRGFyaW4gQWRsZXIuCkluZGV4OiBXZWJDb3JlL3BsYXRmb3JtL2dyYXBoaWNzL0JpdG1h cEltYWdlLmNwcAo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09Ci0tLSBXZWJDb3JlL3BsYXRmb3JtL2dyYXBoaWNzL0JpdG1h cEltYWdlLmNwcAkocmV2aXNpb24gNTQ5NzcpCisrKyBXZWJDb3JlL3BsYXRmb3JtL2dyYXBoaWNz L0JpdG1hcEltYWdlLmNwcAkod29ya2luZyBjb3B5KQpAQCAtMjY2LDYgKzI2NiwxMSBAQCB2b2lk IEJpdG1hcEltYWdlOjpzdGFydEFuaW1hdGlvbihib29sIGNhCiAgICAgaWYgKG1fZnJhbWVUaW1l ciB8fCAhc2hvdWxkQW5pbWF0ZSgpIHx8IGZyYW1lQ291bnQoKSA8PSAxKQogICAgICAgICByZXR1 cm47CiAKKyAgICAvLyBJZiB3ZSBhcmVuJ3QgYWxyZWFkeSBhbmltYXRpbmcsIHNldCBub3cgYXMg dGhlIGFuaW1hdGlvbiBzdGFydCB0aW1lLgorICAgIGNvbnN0IGRvdWJsZSB0aW1lID0gY3VycmVu dFRpbWUoKTsKKyAgICBpZiAoIW1fZGVzaXJlZEZyYW1lU3RhcnRUaW1lKQorICAgICAgICBtX2Rl c2lyZWRGcmFtZVN0YXJ0VGltZSA9IHRpbWU7CisKICAgICAvLyBEb24ndCBhZHZhbmNlIHRoZSBh bmltYXRpb24gdG8gYW4gaW5jb21wbGV0ZSBmcmFtZS4KICAgICBzaXplX3QgbmV4dEZyYW1lID0g KG1fY3VycmVudEZyYW1lICsgMSkgJSBmcmFtZUNvdW50KCk7CiAgICAgaWYgKCFtX2FsbERhdGFS ZWNlaXZlZCAmJiAhZnJhbWVJc0NvbXBsZXRlQXRJbmRleChuZXh0RnJhbWUpKQpAQCAtMjgyLDE5 ICsyODcsMTQgQEAgdm9pZCBCaXRtYXBJbWFnZTo6c3RhcnRBbmltYXRpb24oYm9vbCBjYQogICAg IC8vIGluIHRoaXMgY2FsY3VsYXRpb24sIHdlIG1ha2UgdGhlIGFuaW1hdGlvbiBhcHBlYXIgdG8g cnVuIGF0IGl0cyBkZXNpcmVkCiAgICAgLy8gcmF0ZSByZWdhcmRsZXNzIG9mIGhvdyBmYXN0IGl0 J3MgYmVpbmcgcmVwYWludGVkLgogICAgIGNvbnN0IGRvdWJsZSBjdXJyZW50RHVyYXRpb24gPSBm cmFtZUR1cmF0aW9uQXRJbmRleChtX2N1cnJlbnRGcmFtZSk7Ci0gICAgY29uc3QgZG91YmxlIHRp bWUgPSBjdXJyZW50VGltZSgpOwotICAgIGlmIChtX2Rlc2lyZWRGcmFtZVN0YXJ0VGltZSA9PSAw KSB7Ci0gICAgICAgIG1fZGVzaXJlZEZyYW1lU3RhcnRUaW1lID0gdGltZSArIGN1cnJlbnREdXJh dGlvbjsKLSAgICB9IGVsc2UgewotICAgICAgICBtX2Rlc2lyZWRGcmFtZVN0YXJ0VGltZSArPSBj dXJyZW50RHVyYXRpb247CisgICAgbV9kZXNpcmVkRnJhbWVTdGFydFRpbWUgKz0gY3VycmVudER1 cmF0aW9uOwogCi0gICAgICAgIC8vIFdoZW4gYW4gYW5pbWF0ZWQgaW1hZ2UgaXMgbW9yZSB0aGFu IGZpdmUgbWludXRlcyBvdXQgb2YgZGF0ZSwgdGhlCi0gICAgICAgIC8vIHVzZXIgcHJvYmFibHkg ZG9lc24ndCBjYXJlIGFib3V0IHJlc3luY2luZyBhbmQgd2UgY291bGQgYnVybiBhIGxvdCBvZgot ICAgICAgICAvLyB0aW1lIGxvb3BpbmcgdGhyb3VnaCBmcmFtZXMgYmVsb3cuICBKdXN0IHJlc2V0 IHRoZSB0aW1pbmdzLgotICAgICAgICBjb25zdCBkb3VibGUgY0FuaW1hdGlvblJlc3luY0N1dG9m ZiA9IDUgKiA2MDsKLSAgICAgICAgaWYgKCh0aW1lIC0gbV9kZXNpcmVkRnJhbWVTdGFydFRpbWUp ID4gY0FuaW1hdGlvblJlc3luY0N1dG9mZikKLSAgICAgICAgICAgIG1fZGVzaXJlZEZyYW1lU3Rh cnRUaW1lID0gdGltZSArIGN1cnJlbnREdXJhdGlvbjsKLSAgICB9CisgICAgLy8gV2hlbiBhbiBh bmltYXRlZCBpbWFnZSBpcyBtb3JlIHRoYW4gZml2ZSBtaW51dGVzIG91dCBvZiBkYXRlLCB0aGUK KyAgICAvLyB1c2VyIHByb2JhYmx5IGRvZXNuJ3QgY2FyZSBhYm91dCByZXN5bmNpbmcgYW5kIHdl IGNvdWxkIGJ1cm4gYSBsb3Qgb2YKKyAgICAvLyB0aW1lIGxvb3BpbmcgdGhyb3VnaCBmcmFtZXMg YmVsb3cuICBKdXN0IHJlc2V0IHRoZSB0aW1pbmdzLgorICAgIGNvbnN0IGRvdWJsZSBjQW5pbWF0 aW9uUmVzeW5jQ3V0b2ZmID0gNSAqIDYwOworICAgIGlmICgodGltZSAtIG1fZGVzaXJlZEZyYW1l U3RhcnRUaW1lKSA+IGNBbmltYXRpb25SZXN5bmNDdXRvZmYpCisgICAgICAgIG1fZGVzaXJlZEZy YW1lU3RhcnRUaW1lID0gdGltZSArIGN1cnJlbnREdXJhdGlvbjsKIAogICAgIC8vIFRoZSBpbWFn ZSBtYXkgbG9hZCBtb3JlIHNsb3dseSB0aGFuIGl0J3Mgc3VwcG9zZWQgdG8gYW5pbWF0ZSwgc28g dGhhdCBieQogICAgIC8vIHRoZSB0aW1lIHdlIHJlYWNoIHRoZSBlbmQgb2YgdGhlIGZpcnN0IHJl cGV0aXRpb24sIHdlJ3JlIHdlbGwgYmVoaW5kLgpAQCAtMzA3LDcgKzMwNyw3IEBAIHZvaWQgQml0 bWFwSW1hZ2U6OnN0YXJ0QW5pbWF0aW9uKGJvb2wgY2EKICAgICAvLyBzd2l0Y2ggdGFicyAoYW5k IHRodXMgc3RvcCBkcmF3aW5nIHRoZSBhbmltYXRpb24sIHdoaWNoIHdpbGwgcGF1c2UgaXQpCiAg ICAgLy8gZHVyaW5nIHRoYXQgaW5pdGlhbCBsb29wLCB0aGVuIHN3aXRjaCBiYWNrIGxhdGVyLgog ICAgIGlmIChuZXh0RnJhbWUgPT0gMCAmJiBtX3JlcGV0aXRpb25zQ29tcGxldGUgPT0gMCAmJiBt X2Rlc2lyZWRGcmFtZVN0YXJ0VGltZSA8IHRpbWUpCi0gICAgICBtX2Rlc2lyZWRGcmFtZVN0YXJ0 VGltZSA9IHRpbWU7CisgICAgICAgIG1fZGVzaXJlZEZyYW1lU3RhcnRUaW1lID0gdGltZTsKIAog ICAgIGlmICghY2F0Y2hVcElmTmVjZXNzYXJ5IHx8IHRpbWUgPCBtX2Rlc2lyZWRGcmFtZVN0YXJ0 VGltZSkgewogICAgICAgICAvLyBIYXZlbid0IHlldCByZWFjaGVkIHRpbWUgZm9yIG5leHQgZnJh bWUgdG8gc3RhcnQ7IGRlbGF5IHVudGlsIHRoZW4uCg==