79267 2012-02-22 12:31:18 -0800 [chromium] Reset damage tracker on visibility change. 2012-02-28 16:35:28 -0800 1 1 1 Unclassified WebKit New Bugs 528+ (Nightly build) Unspecified Unspecified RESOLVED FIXED P2 Normal --- 1 backer backer cc-bugs commit-queue jamesr mmocny nduca shawnsingh webkit.review.bot oldest_to_newest 562251 0 backer 2012-02-22 12:31:18 -0800 [chromium] Reset damage tracker on visibility change. 562254 1 128265 backer 2012-02-22 12:32:44 -0800 Created attachment 128265 Patch 562266 2 backer 2012-02-22 12:40:37 -0800 This is mostly for Aura Chromium, but I think it may translate to Win 7 Chromium as well. When a tab goes into the background, we reclaim the back buffer which disassociates the front and back buffer. When we go to the foreground, we get a new back buffer/front buffer pair, whose front buffer is in a undefined state. So we should push a full frame to the front buffer on the next composite cycle. On Aura chrome, the tab does not get an expose event, so we can't rely on a the damage tracker reset to be propagated from the browser via RenderWidget::OnMsgRepaint. The two reset paths are complementary (we need both for Aura --- one for vterm switch and one for tab switch). 562302 3 backer 2012-02-22 13:10:18 -0800 Just a few additional thoughts: we probably want something like this for when we drop front buffers too (when we have too many tabs open). We could definitely do this for OSX, Win7, and Aura --- possibly other platforms. 562312 4 mmocny 2012-02-22 13:17:33 -0800 We certainly want to do this for dropped frontbuffers as well. From the looks of the CL it looks like this change will affect all platforms, but your comments hint at the opposite. May you confirm one way or the other? 562339 5 backer 2012-02-22 13:38:48 -0800 (In reply to comment #4) > We certainly want to do this for dropped frontbuffers as well. From the looks of the CL it looks like this change will affect all platforms, but your comments hint at the opposite. May you confirm one way or the other? I think that we want to do this for all platforms. It's conservative and I think that it will serve us well in the future. That said, this is motivated by a bug found in the wild for Aura (early adopter of partial swaps): http://code.google.com/p/chromium/issues/detail?id=115280 562434 6 nduca 2012-02-22 15:14:47 -0800 iirw, we already route the GpuMemoryManager's decision to drop a frontbuffer/backbuffer to the stub and then up to the RendererGLContext. We should modify the WebGraphicsContext3D callback and the Extensions3DChromium callbacks to take a struct as well [I'm not clear why we didn't do that in the first place]. In that struct, we should pass whether a back/front was allocated. The compositor should then hook up to the callback, and in the callback, take the right actions when, for example, a backbuffer goes away. 563138 7 mmocny 2012-02-23 08:47:15 -0800 The changes to the callback are easy, and likely the right way forward, so I'll get started on a patch. However, I worry about a possible race when rapid tab switching between two tabs, where the callback may not be delivered in a timely enough manner (we would be expecting to receive the callback before the next visibility change, which isn't guaranteed). The current model is that the memory allocations are asynchronous hints and may reflect a previous state-of-the-world. One solution may be to add a wait-for-memory-allocation in the renderer, if and only if there is a subsequent visibility change and the current memory allocation is not yet received. Once/if visibility changes start going to the gpu process directly from the browser, things will change - may become more complicated. 563412 8 nduca 2012-02-23 13:30:42 -0800 Okay, I think I see the underlying problem here. Its that the GPU process is doing the drop of the backbuffer on its own. That is what is getting us into hot water. If instead the GPU process just sends a new allocation to the renderer with backbuffer=false, and we add API to GL to drop the backbuffer, then we don't get this race. I dont think latency would be impacted negatively either... a few milliseconds at most are added to the flow. WDYT? 563467 9 mmocny 2012-02-23 14:14:05 -0800 sgtm, it seemed inevitable that we would need to synchronize dropping buffers between renderer and gpu and that seems like a very clean way to do it. Though I think the memory allocation struct will warrant a renaming to shouldHave*Buffer, and the renderer may need to track current buffer allocation state or else send needless IPC on each memory allocation change (which may be acceptable now, but will become more frequent than just on tab switch). fwiw, we discussed a simpler fix for the original issue here: currently on aura we dont force a paint on tab foregrounding (we do on (all?) other platforms). Adding that would fix the damage tracker issue, as well as a similar issue which will arise when dropping frontbuffers. Both issues can be solved using a MemoryAllocationChangedCallback, and I'm not sure if we want both solutions. 563512 10 nduca 2012-02-23 14:49:56 -0800 (In reply to comment #9) > sgtm, it seemed inevitable that we would need to synchronize dropping buffers between renderer and gpu and that seems like a very clean way to do it. Though I think the memory allocation struct will warrant a renaming to shouldHave*Buffer, and the renderer may need to track current buffer allocation state or else send needless IPC on each memory allocation change (which may be acceptable now, but will become more frequent than just on tab switch). Great point about naming. This underscores the value in making the callbacks on webkit side take a struct as an argument. I dont see a lot of risk in sending memory managment callbacks every frame, even. IPCs are not themselves that heavy. > fwiw, we discussed a simpler fix for the original issue here: currently on aura we dont force a paint on tab foregrounding (we do on (all?) other platforms). Adding that would fix the damage tracker issue, as well as a similar issue which will arise when dropping frontbuffers. Totally, but this is a hack, right? I think that'd make fast tab switching heavier because you'd end up repainting all the time when you switch tabs, too. If we're under OMGOMGFIXRIGHTAWAY pressure, I'm personally fine with a temporary fix for it, but I think the underlying issue is probably also worth working-toward. 564327 11 backer 2012-02-24 07:57:38 -0800 > Totally, but this is a hack, right? I think that'd make fast tab switching heavier because you'd end up repainting all the time when you switch tabs, too. This patch is not a hack. It is the right thing to do. a) we shouldn't release any buffers (front or back) unless that tab is not visible regardless of any co-ordination scheme you can come up with but more importantly b) once the tab is made visible, we should not make any assumptions about the buffer state, regardless of buffer management, because any assumptions would be platform specific (e.g. on desktop linux the front buffer is in a bad state and needs to be completely redrawn --- this particular example is mitigated by the XExpose event being propagated from the browser and causing a full frame damage). This change is safe. The only drawback that I see, is that it isn't obvious why it is needed. I think that could be resolved with a comment/renaming, or perhaps putting a check that we're using partial swaps before forcing the damage reset. > If we're under OMGOMGFIXRIGHTAWAY pressure, I'm personally fine with a temporary fix for it, but I think the underlying issue is probably also worth working-toward. We've got about 2 weeks for fix this. The sooner the better. 564825 12 jamesr 2012-02-24 19:11:23 -0800 To rephrase Nat's concern (which I agree with completely, if I understand it correctly) our world will be a lot simpler if all decisions about a context's resources are made by the compositor and not externally to it. If we want to drop the back buffer, we should tell the compositor and let it issue a command into the GL command stream to do so. If we want it to drop some textures, tell the compositor and let it issue the appropriate glDelete*() calls. That way the compositor is aware at all times of what it does and does not have and the compositor's GL command stream is always internally consistent with the resources it has available in the GPU process. Is that a fair summary? If there are cases where in the GPU process we absolutely must free up resources and we cannot afford to wait for a compositor to respond to an async message, then we should kill the context outright and let the lost context mechanism handle recovery. You're right, Jonathan, that front buffer damage on a non-composited WM is something that is out of our control completely. It's not triggered by the GPU process or the compositor's actions and so we have to react asynchronously to it. I think this is a unique special case and not a sign of a more general issue. The backbuffer in particular is a GL resource that our code has complete control over. 564826 13 128265 jamesr 2012-02-24 19:12:29 -0800 Comment on attachment 128265 Patch R- since I'm concerned about very hard to deal with flashes resulting from this approach, see the preceding few comments for what I think would be a more workable approach. 565600 14 backer 2012-02-27 06:02:57 -0800 > To rephrase Nat's concern (which I agree with completely, if I understand it correctly) our world will be a lot simpler if all decisions about a context's resources are made by the compositor and not externally to it. If we want to drop the back buffer, we should tell the compositor and let it issue a command into the GL command stream to do so. If we want it to drop some textures, tell the compositor and let it issue the appropriate glDelete*() calls. That way the compositor is aware at all times of what it does and does not have and the compositor's GL command stream is always internally consistent with the resources it has available in the GPU process. Is that a fair summary? That's a fair summary, and I don't disagree with it --- within limits. Let's go back to the Linux desktop example: it's the browser that determines the visibility of the tab contents window; when the window is hidden, the the front buffer is trashed; neither the renderer nor the GPU process get any say in this decision (and they shouldn't); but we've got an async message sent to the renderer for the visibility change --- I think that we should respond to this by resetting the damage tracker. Note that in this example, the front buffer is not necessarily freed (I think that this is driver dependent --- I'd want to resize that unmapped window to guarantee it). Allowing the renderer to drive this decision is fine (and consistent with the position that Nat advocates). (In reply to comment #13) > (From update of attachment 128265 [details]) > R- since I'm concerned about very hard to deal with flashes resulting from this approach, see the preceding few comments for what I think would be a more workable approach. This patch isn't about addressing flashing. Flashing is a bad user experience (but somewhat bearable). With --enable-partial-swap, this is about most of the screen not being drawn, and fragments being drawn as we mouse over --- a horrific user experience. We need to reset the damage tracker. It needs to be reset based on visibility change (somehow). This problem is mitigated on desktop Linux where we get a full frame damage based on XExpose (there's a race but it looks like a flash to the user). But we don't get that XExpose event on Aura (only the root window in an X window on Aura --- everything else is a composited texture). Hence, why I want to do a conservative, platform-independent reset on visibility change. Alternatively, I can force a reset in Aura on the Chromium side via the same mechanism used by desktop Linux with XExpose --- but I think this is the wrong approach (too platform specific --- I want to code partial swaps/scissoring to the lowest common denominator). @jamesr: Please reconsider. 565749 15 jamesr 2012-02-27 09:48:55 -0800 Is the reason we need to reset on visibility change in Aura because the OS is doing something outside our control, or because we're dropping a resource? 565801 16 backer 2012-02-27 10:39:54 -0800 (In reply to comment #15) > Is the reason we need to reset on visibility change in Aura because the OS is doing something outside our control, or because we're dropping a resource? Hmm... I think that in this case, it's in our control. AFAIK, it is due to dropping the backbuffer on GLX image transport. That said, Aura now has 4 different backends for texture transport: GLX, EGL, OSMesa, and GPU process (behind a --ui-use-gpu-process flag). Eventually we will move to just the later (yes!!!!). I think that this bug only affects the GLX backend... not the others. But this is my point --- if we don't do this, we're making platform specific decisions. Without the XExpose on desktop linux, we'd have the same problem there. The performance hit on a full frame damage is negligible and we really shouldn't make any assumptions about the state of the buffers. I take to heart that there's a danger that we paper over other bugs. But I just don't think that's the case here. 565939 17 nduca 2012-02-27 13:50:08 -0800 (In reply to comment #16) > (In reply to comment #15) What are the semantics of the frontbuffer with the post-sub extension? 566597 18 129233 backer 2012-02-28 05:27:01 -0800 Created attachment 129233 Patch 566598 19 129233 backer 2012-02-28 05:30:54 -0800 Comment on attachment 129233 Patch Updated as per offline discussion and filed tracking bug (link in comments) for future work. 566868 20 129233 jamesr 2012-02-28 10:54:25 -0800 Comment on attachment 129233 Patch View in context: https://bugs.webkit.org/attachment.cgi?id=129233&action=review > Source/WebCore/platform/graphics/chromium/LayerRendererChromium.cpp:296 > + // process on visibility change. is it damaged every time visibility changes? I thought it was only damaged on the visible -> not visible transition. 566870 21 jamesr 2012-02-28 10:56:50 -0800 Also can you add tests for this? We have CCDamageTrackerTest.cpp, this might fit in there. 567078 22 129328 backer 2012-02-28 14:12:57 -0800 Created attachment 129328 Patch 567082 23 129328 backer 2012-02-28 14:17:37 -0800 Comment on attachment 129328 Patch (In reply to comment #20) > (From update of attachment 129233 [details]) > View in context: https://bugs.webkit.org/attachment.cgi?id=129233&action=review > > > Source/WebCore/platform/graphics/chromium/LayerRendererChromium.cpp:296 > > + // process on visibility change. > > is it damaged every time visibility changes? I thought it was only damaged on the visible -> not visible transition. Correct. It will be damaged when made invisible. I've updated the CL to damage on the transition to visible because I want the damage clear at this point (we're about to push a new frame). I should work just as well by clearing on the change to invisible. Your call. (In reply to comment #21) > Also can you add tests for this? We have CCDamageTrackerTest.cpp, this might fit in there. Added a unit test to CCLayerTreeHostImpl.cpp by adding a test similar to an existing test there. 567104 24 129328 jamesr 2012-02-28 14:31:31 -0800 Comment on attachment 129328 Patch Awesome, R=me. I think either behavior for visibility transitions is fine so long as we're clear about it and have tests to make sure we don't break it, since we never draw when !visible. 567215 25 129328 webkit.review.bot 2012-02-28 16:35:22 -0800 Comment on attachment 129328 Patch Clearing flags on attachment: 129328 Committed r109168: <http://trac.webkit.org/changeset/109168> 567216 26 webkit.review.bot 2012-02-28 16:35:28 -0800 All reviewed patches have been landed. Closing bug. 128265 2012-02-22 12:32:44 -0800 2012-02-28 05:26:56 -0800 Patch bug-79267-20120222153243.patch text/plain 1392 backer U3VidmVyc2lvbiBSZXZpc2lvbjogMTA4NDY3CmRpZmYgLS1naXQgYS9Tb3VyY2UvV2ViQ29yZS9D aGFuZ2VMb2cgYi9Tb3VyY2UvV2ViQ29yZS9DaGFuZ2VMb2cKaW5kZXggNmY1ZGI1YmYzZjRmYjYy NmJlYjIyNjUxZTI2NzVjOTM2Zjk3YTVmMC4uZDM4YTA5NmVjNjE5OTY2MzE0MGNhYmI1NmEzNWY0 MzJkYWU5MGUzNCAxMDA2NDQKLS0tIGEvU291cmNlL1dlYkNvcmUvQ2hhbmdlTG9nCisrKyBiL1Nv dXJjZS9XZWJDb3JlL0NoYW5nZUxvZwpAQCAtMSwzICsxLDEzIEBACisyMDEyLTAyLTIyICBKb25h dGhhbiBCYWNrZXIgIDxiYWNrZXJAY2hyb21pdW0ub3JnPgorCisgICAgICAgIFtjaHJvbWl1bV0g UmVzZXQgZGFtYWdlIHRyYWNrZXIgb24gdmlzaWJpbGl0eSBjaGFuZ2UuCisgICAgICAgIGh0dHBz Oi8vYnVncy53ZWJraXQub3JnL3Nob3dfYnVnLmNnaT9pZD03OTI2NworCisgICAgICAgIFJldmll d2VkIGJ5IE5PQk9EWSAoT09QUyEpLgorCisgICAgICAgICogcGxhdGZvcm0vZ3JhcGhpY3MvY2hy b21pdW0vY2MvQ0NMYXllclRyZWVIb3N0SW1wbC5jcHA6CisgICAgICAgIChXZWJDb3JlOjpDQ0xh eWVyVHJlZUhvc3RJbXBsOjpzZXRWaXNpYmxlKToKKwogMjAxMi0wMi0yMiAgWXV0YSBLaXRhbXVy YSAgPHl1dGFrQGNocm9taXVtLm9yZz4KIAogICAgICAgICBVbnJldmlld2VkLCByb2xsaW5nIG91 dCByMTA4NDUzLgpkaWZmIC0tZ2l0IGEvU291cmNlL1dlYkNvcmUvcGxhdGZvcm0vZ3JhcGhpY3Mv Y2hyb21pdW0vY2MvQ0NMYXllclRyZWVIb3N0SW1wbC5jcHAgYi9Tb3VyY2UvV2ViQ29yZS9wbGF0 Zm9ybS9ncmFwaGljcy9jaHJvbWl1bS9jYy9DQ0xheWVyVHJlZUhvc3RJbXBsLmNwcAppbmRleCA3 NjhhYzJmMmEzNTM2ZWQ1OTg2MTVmYTNjZjBmMmIwYjM3ZDdhOTEwLi41ZjNjZWExYmU4NTM1Y2Fh NDQ1ZTYxYTFmZDBlNThiNzcwY2JjMzQzIDEwMDY0NAotLS0gYS9Tb3VyY2UvV2ViQ29yZS9wbGF0 Zm9ybS9ncmFwaGljcy9jaHJvbWl1bS9jYy9DQ0xheWVyVHJlZUhvc3RJbXBsLmNwcAorKysgYi9T b3VyY2UvV2ViQ29yZS9wbGF0Zm9ybS9ncmFwaGljcy9jaHJvbWl1bS9jYy9DQ0xheWVyVHJlZUhv c3RJbXBsLmNwcApAQCAtMzYzLDYgKzM2Myw5IEBAIHZvaWQgQ0NMYXllclRyZWVIb3N0SW1wbDo6 c2V0VmlzaWJsZShib29sIHZpc2libGUpCiAKICAgICBpZiAobV9sYXllclJlbmRlcmVyKQogICAg ICAgICBtX2xheWVyUmVuZGVyZXItPnNldFZpc2libGUodmlzaWJsZSk7CisKKyAgICBpZiAobV92 aXNpYmxlKQorICAgICAgICBzZXRGdWxsUm9vdExheWVyRGFtYWdlKCk7CiB9CiAKIGJvb2wgQ0NM YXllclRyZWVIb3N0SW1wbDo6aW5pdGlhbGl6ZUxheWVyUmVuZGVyZXIoUGFzc1JlZlB0cjxHcmFw aGljc0NvbnRleHQzRD4gY29udGV4dCkK 129233 2012-02-28 05:27:01 -0800 2012-02-28 14:12:54 -0800 Patch bug-79267-20120228082659.patch text/plain 1871 backer U3VidmVyc2lvbiBSZXZpc2lvbjogMTA4OTg3CmRpZmYgLS1naXQgYS9Tb3VyY2UvV2ViQ29yZS9D aGFuZ2VMb2cgYi9Tb3VyY2UvV2ViQ29yZS9DaGFuZ2VMb2cKaW5kZXggY2QzMzg3NGQwNGM1N2Uz OWIzZTY2YjY5NDc1NGE3MzAxNzgyNWEzOC4uYzAyMmI1MGQxNTI4OTAyMmUwMWRiNDE1MWE2MzRl MzEyN2ExMDMwYiAxMDA2NDQKLS0tIGEvU291cmNlL1dlYkNvcmUvQ2hhbmdlTG9nCisrKyBiL1Nv dXJjZS9XZWJDb3JlL0NoYW5nZUxvZwpAQCAtMSwzICsxLDEzIEBACisyMDEyLTAyLTI4ICBKb25h dGhhbiBCYWNrZXIgIDxiYWNrZXJAY2hyb21pdW0ub3JnPgorCisgICAgICAgIFtjaHJvbWl1bV0g UmVzZXQgZGFtYWdlIHRyYWNrZXIgb24gdmlzaWJpbGl0eSBjaGFuZ2UuCisgICAgICAgIGh0dHBz Oi8vYnVncy53ZWJraXQub3JnL3Nob3dfYnVnLmNnaT9pZD03OTI2NworCisgICAgICAgIFJldmll d2VkIGJ5IE5PQk9EWSAoT09QUyEpLgorCisgICAgICAgICogcGxhdGZvcm0vZ3JhcGhpY3MvY2hy b21pdW0vTGF5ZXJSZW5kZXJlckNocm9taXVtLmNwcDoKKyAgICAgICAgKFdlYkNvcmU6OkxheWVy UmVuZGVyZXJDaHJvbWl1bTo6c2V0VmlzaWJsZSk6CisKIDIwMTItMDItMjcgIFl1cnkgU2VtaWto YXRza3kgIDx5dXJ5c0BjaHJvbWl1bS5vcmc+CiAKICAgICAgICAgV2ViIEluc3BlY3RvcjogcmVw YWludCBjb3VudGVyIGdyYXBocyB3aGVuIHRpbWVsaW5lIHNwbGl0dGVyIG1vdmVzCmRpZmYgLS1n aXQgYS9Tb3VyY2UvV2ViQ29yZS9wbGF0Zm9ybS9ncmFwaGljcy9jaHJvbWl1bS9MYXllclJlbmRl cmVyQ2hyb21pdW0uY3BwIGIvU291cmNlL1dlYkNvcmUvcGxhdGZvcm0vZ3JhcGhpY3MvY2hyb21p dW0vTGF5ZXJSZW5kZXJlckNocm9taXVtLmNwcAppbmRleCA1NDJiM2FkMWM0MjcxMzMzMzIxNzgx OWIxODhlZmIzZGRmNzU1Nzg1Li5hMTk5N2Q5MzA2YzEzMzZlNjJlODBjZTlmYzA4Y2NlYjlhMDhh ODNiIDEwMDY0NAotLS0gYS9Tb3VyY2UvV2ViQ29yZS9wbGF0Zm9ybS9ncmFwaGljcy9jaHJvbWl1 bS9MYXllclJlbmRlcmVyQ2hyb21pdW0uY3BwCisrKyBiL1NvdXJjZS9XZWJDb3JlL3BsYXRmb3Jt L2dyYXBoaWNzL2Nocm9taXVtL0xheWVyUmVuZGVyZXJDaHJvbWl1bS5jcHAKQEAgLTI4NSw5ICsy ODUsMTcgQEAgdm9pZCBMYXllclJlbmRlcmVyQ2hyb21pdW06OnNldFZpc2libGUoYm9vbCB2aXNp YmxlKQogewogICAgIGlmICghdmlzaWJsZSkKICAgICAgICAgcmVsZWFzZVJlbmRlclN1cmZhY2VU ZXh0dXJlcygpOworCisgICAgLy8gVE9ETzogUmVwbGFjZSBzZXRWaXNpYmlsaXR5Q0hST01JVU0g d2l0aCBhbiBleHRlbnNpb24gdG8gZXhwbGljaXRseSBtYW5hZ2UgZnJvbnQvYmFja2J1ZmZlcnMK KyAgICAvLyBjcmJ1Zy5jb20vMTE2MDQ5CiAgICAgaWYgKG1fY2FwYWJpbGl0aWVzLnVzaW5nU2V0 VmlzaWJpbGl0eSkgewogICAgICAgICBFeHRlbnNpb25zM0RDaHJvbWl1bSogZXh0ZW5zaW9uczNE Q2hyb21pdW0gPSBzdGF0aWNfY2FzdDxFeHRlbnNpb25zM0RDaHJvbWl1bSo+KG1fY29udGV4dC0+ Z2V0RXh0ZW5zaW9ucygpKTsKICAgICAgICAgZXh0ZW5zaW9uczNEQ2hyb21pdW0tPnNldFZpc2li aWxpdHlDSFJPTUlVTSh2aXNpYmxlKTsKKworICAgICAgICAvLyBSZXNldCB0aGUgZGFtYWdlIHRy YWNrZXIgYmVjYXVzZSB0aGUgZnJvbnQvYmFjayBidWZmZXJzIG1heSBoYXZlIGJlZW4gZGFtYWdl ZCBieSB0aGUgR1BVCisgICAgICAgIC8vIHByb2Nlc3Mgb24gdmlzaWJpbGl0eSBjaGFuZ2UuCisg ICAgICAgIGlmIChtX2NhcGFiaWxpdGllcy51c2luZ1BhcnRpYWxTd2FwKQorICAgICAgICAgICAg bV9vd25lci0+c2V0RnVsbFJvb3RMYXllckRhbWFnZSgpOwogICAgIH0KIH0KIAo= 129328 2012-02-28 14:12:57 -0800 2012-02-28 16:35:22 -0800 Patch bug-79267-20120228171256.patch text/plain 5678 backer U3VidmVyc2lvbiBSZXZpc2lvbjogMTA5MTAxCmRpZmYgLS1naXQgYS9Tb3VyY2UvV2ViQ29yZS9D aGFuZ2VMb2cgYi9Tb3VyY2UvV2ViQ29yZS9DaGFuZ2VMb2cKaW5kZXggODhhNThhMTVmZGViYTc3 ZTUxY2YyZWRiNDE2YzNiNzBlYmU0OGM1MC4uNmM1Zjk5ZDc3MTdkMzc4ZTM4YjU0ZjY2YTQ2MmUw YmU4NGRjOTg0MyAxMDA2NDQKLS0tIGEvU291cmNlL1dlYkNvcmUvQ2hhbmdlTG9nCisrKyBiL1Nv dXJjZS9XZWJDb3JlL0NoYW5nZUxvZwpAQCAtMSwzICsxLDE1IEBACisyMDEyLTAyLTI4ICBKb25h dGhhbiBCYWNrZXIgIDxiYWNrZXJAY2hyb21pdW0ub3JnPgorCisgICAgICAgIFtjaHJvbWl1bV0g UmVzZXQgZGFtYWdlIHRyYWNrZXIgb24gdmlzaWJpbGl0eSBjaGFuZ2UuCisgICAgICAgIGh0dHBz Oi8vYnVncy53ZWJraXQub3JnL3Nob3dfYnVnLmNnaT9pZD03OTI2NworCisgICAgICAgIFJldmll d2VkIGJ5IE5PQk9EWSAoT09QUyEpLgorCisgICAgICAgIFVuaXQgdGVzdHM6IENDTGF5ZXJUcmVl SG9zdEltcGxUZXN0LmNwcAorCisgICAgICAgICogcGxhdGZvcm0vZ3JhcGhpY3MvY2hyb21pdW0v TGF5ZXJSZW5kZXJlckNocm9taXVtLmNwcDoKKyAgICAgICAgKFdlYkNvcmU6OkxheWVyUmVuZGVy ZXJDaHJvbWl1bTo6c2V0VmlzaWJsZSk6CisKIDIwMTItMDItMjggIE5pa29sYXMgWmltbWVybWFu biAgPG56aW1tZXJtYW5uQHJpbS5jb20+CiAKICAgICAgICAgSW50ZWdyYXRlIFNWR1VzZUVsZW1l bnQgd2l0aGluIHRoZSBuZXcgc2hhZG93IHJvb3QgY29uY2VwdApkaWZmIC0tZ2l0IGEvU291cmNl L1dlYktpdC9jaHJvbWl1bS9DaGFuZ2VMb2cgYi9Tb3VyY2UvV2ViS2l0L2Nocm9taXVtL0NoYW5n ZUxvZwppbmRleCA2OGQyOGY1MzQyZjhhNGE5MmM1YWJjNDNjZWNjYjk2YjgyYjQxZmUwLi4wMzhk ZjJkYzI4MzVhZWFjMDU4OTM3M2FhZmNiNGQxOGRjNjU5MzJlIDEwMDY0NAotLS0gYS9Tb3VyY2Uv V2ViS2l0L2Nocm9taXVtL0NoYW5nZUxvZworKysgYi9Tb3VyY2UvV2ViS2l0L2Nocm9taXVtL0No YW5nZUxvZwpAQCAtMSwzICsxLDE1IEBACisyMDEyLTAyLTI4ICBKb25hdGhhbiBCYWNrZXIgIDxi YWNrZXJAY2hyb21pdW0ub3JnPgorCisgICAgICAgIFtjaHJvbWl1bV0gUmVzZXQgZGFtYWdlIHRy YWNrZXIgb24gdmlzaWJpbGl0eSBjaGFuZ2UuCisgICAgICAgIGh0dHBzOi8vYnVncy53ZWJraXQu b3JnL3Nob3dfYnVnLmNnaT9pZD03OTI2NworCisgICAgICAgIFJldmlld2VkIGJ5IE5PQk9EWSAo T09QUyEpLgorCisgICAgICAgICogdGVzdHMvQ0NMYXllclRyZWVIb3N0SW1wbFRlc3QuY3BwOgor ICAgICAgICAoV2ViS2l0OjpQYXJ0aWFsU3dhcFRyYWNrZXJDb250ZXh0OjpnZXRTdHJpbmcpOgor ICAgICAgICAoV2ViS2l0KToKKyAgICAgICAgKFdlYktpdDo6VEVTVF9GKToKKwogMjAxMi0wMi0y NyAgSmFtZXMgS296aWFuc2tpICA8a296QGNocm9taXVtLm9yZz4KIAogICAgICAgICBBZGQgbWlz c2luZyBwYXJhbWV0ZXIgdG8gZGlkQ3JlYXRlU2NyaXB0Q29udGV4dCgpIHNvIGl0IG92ZXJyaWRl cyBiYXNlIGNsYXNzIGFnYWluLgpkaWZmIC0tZ2l0IGEvU291cmNlL1dlYkNvcmUvcGxhdGZvcm0v Z3JhcGhpY3MvY2hyb21pdW0vTGF5ZXJSZW5kZXJlckNocm9taXVtLmNwcCBiL1NvdXJjZS9XZWJD b3JlL3BsYXRmb3JtL2dyYXBoaWNzL2Nocm9taXVtL0xheWVyUmVuZGVyZXJDaHJvbWl1bS5jcHAK aW5kZXggNTQyYjNhZDFjNDI3MTMzMzMyMTc4MTliMTg4ZWZiM2RkZjc1NTc4NS4uMDRlNDczMjEz YTc0ZWJlN2QzNzhmOGQ3NjQ4ODQwYzIzOTg3NmQ2MCAxMDA2NDQKLS0tIGEvU291cmNlL1dlYkNv cmUvcGxhdGZvcm0vZ3JhcGhpY3MvY2hyb21pdW0vTGF5ZXJSZW5kZXJlckNocm9taXVtLmNwcAor KysgYi9Tb3VyY2UvV2ViQ29yZS9wbGF0Zm9ybS9ncmFwaGljcy9jaHJvbWl1bS9MYXllclJlbmRl cmVyQ2hyb21pdW0uY3BwCkBAIC0yODUsOSArMjg1LDE3IEBAIHZvaWQgTGF5ZXJSZW5kZXJlckNo cm9taXVtOjpzZXRWaXNpYmxlKGJvb2wgdmlzaWJsZSkKIHsKICAgICBpZiAoIXZpc2libGUpCiAg ICAgICAgIHJlbGVhc2VSZW5kZXJTdXJmYWNlVGV4dHVyZXMoKTsKKworICAgIC8vIFRPRE86IFJl cGxhY2Ugc2V0VmlzaWJpbGl0eUNIUk9NSVVNIHdpdGggYW4gZXh0ZW5zaW9uIHRvIGV4cGxpY2l0 bHkgbWFuYWdlIGZyb250L2JhY2tidWZmZXJzCisgICAgLy8gY3JidWcuY29tLzExNjA0OQogICAg IGlmIChtX2NhcGFiaWxpdGllcy51c2luZ1NldFZpc2liaWxpdHkpIHsKICAgICAgICAgRXh0ZW5z aW9uczNEQ2hyb21pdW0qIGV4dGVuc2lvbnMzRENocm9taXVtID0gc3RhdGljX2Nhc3Q8RXh0ZW5z aW9uczNEQ2hyb21pdW0qPihtX2NvbnRleHQtPmdldEV4dGVuc2lvbnMoKSk7CiAgICAgICAgIGV4 dGVuc2lvbnMzRENocm9taXVtLT5zZXRWaXNpYmlsaXR5Q0hST01JVU0odmlzaWJsZSk7CisKKyAg ICAgICAgLy8gUmVzZXQgdGhlIGRhbWFnZSB0cmFja2VyIGJlY2F1c2UgdGhlIGZyb250L2JhY2sg YnVmZmVycyBtYXkgaGF2ZSBiZWVuIGRhbWFnZWQgYnkgdGhlIEdQVQorICAgICAgICAvLyBwcm9j ZXNzIG9uIHZpc2liaWxpdHkgY2hhbmdlLgorICAgICAgICBpZiAodmlzaWJsZSAmJiBtX2NhcGFi aWxpdGllcy51c2luZ1BhcnRpYWxTd2FwKQorICAgICAgICAgICAgbV9vd25lci0+c2V0RnVsbFJv b3RMYXllckRhbWFnZSgpOwogICAgIH0KIH0KIApkaWZmIC0tZ2l0IGEvU291cmNlL1dlYktpdC9j aHJvbWl1bS90ZXN0cy9DQ0xheWVyVHJlZUhvc3RJbXBsVGVzdC5jcHAgYi9Tb3VyY2UvV2ViS2l0 L2Nocm9taXVtL3Rlc3RzL0NDTGF5ZXJUcmVlSG9zdEltcGxUZXN0LmNwcAppbmRleCAyMGM3NjI5 M2ExZWFlZTI1N2FiMjM1MGI0ZGNjOWY5MTVkMzdhODUyLi5mZWNiOTNmNjZiNTIxM2QxNmZhNWI0 YTUxNDRmZTY1M2I2NTU4YzgxIDEwMDY0NAotLS0gYS9Tb3VyY2UvV2ViS2l0L2Nocm9taXVtL3Rl c3RzL0NDTGF5ZXJUcmVlSG9zdEltcGxUZXN0LmNwcAorKysgYi9Tb3VyY2UvV2ViS2l0L2Nocm9t aXVtL3Rlc3RzL0NDTGF5ZXJUcmVlSG9zdEltcGxUZXN0LmNwcApAQCAtNzQ1LDcgKzc0NSw3IEBA IHB1YmxpYzoKICAgICB2aXJ0dWFsIFdlYlN0cmluZyBnZXRTdHJpbmcoV0dDM0RlbnVtIG5hbWUp CiAgICAgewogICAgICAgICBpZiAobmFtZSA9PSBHcmFwaGljc0NvbnRleHQzRDo6RVhURU5TSU9O UykKLSAgICAgICAgICAgIHJldHVybiBXZWJTdHJpbmcoIkdMX0NIUk9NSVVNX3Bvc3Rfc3ViX2J1 ZmZlciIpOworICAgICAgICAgICAgcmV0dXJuIFdlYlN0cmluZygiR0xfQ0hST01JVU1fcG9zdF9z dWJfYnVmZmVyIEdMX0NIUk9NSVVNX3NldF92aXNpYmlsaXR5Iik7CiAKICAgICAgICAgcmV0dXJu IFdlYlN0cmluZygpOwogICAgIH0KQEAgLTgyMiw0ICs4MjIsNDcgQEAgVEVTVF9GKENDTGF5ZXJU cmVlSG9zdEltcGxUZXN0LCBwYXJ0aWFsU3dhcFJlY2VpdmVzRGFtYWdlUmVjdCkKICAgICBFWFBF Q1RfRVEoZXhwZWN0ZWRTd2FwUmVjdC5oZWlnaHQoKSwgYWN0dWFsU3dhcFJlY3QuaGVpZ2h0KCkp OwogfQogCisvLyBNYWtlIHN1cmUgdGhhdCB3ZSByZXNldCBkYW1hZ2UgdHJhY2tpbmcgb24gdmlz aWJpbGl0eSBjaGFuZ2UgYmVjYXVzZSB0aGUKKy8vIHN0YXRlIG9mIHRoZSBmcm9udCBidWZmZXIg dGhhdCB3ZSBwdXNoIHRvIHdpdGggUG9zdFN1YkJ1ZmZlciBpcyB1bmRlZmluZWQuCitURVNUX0Yo Q0NMYXllclRyZWVIb3N0SW1wbFRlc3QsIHZpc2liaWxpdHlDaGFuZ2VSZXNldHNEYW1hZ2UpCit7 CisgICAgUGFydGlhbFN3YXBUcmFja2VyQ29udGV4dCogcGFydGlhbFN3YXBUcmFja2VyID0gbmV3 IFBhcnRpYWxTd2FwVHJhY2tlckNvbnRleHQoKTsKKyAgICBSZWZQdHI8R3JhcGhpY3NDb250ZXh0 M0Q+IGNvbnRleHQgPSBHcmFwaGljc0NvbnRleHQzRFByaXZhdGU6OmNyZWF0ZUdyYXBoaWNzQ29u dGV4dEZyb21XZWJDb250ZXh0KGFkb3B0UHRyKHBhcnRpYWxTd2FwVHJhY2tlciksIEdyYXBoaWNz Q29udGV4dDNEOjpSZW5kZXJEaXJlY3RseVRvSG9zdFdpbmRvdyk7CisKKyAgICAvLyBUaGlzIHRl c3QgY3JlYXRlcyBpdHMgb3duIENDTGF5ZXJUcmVlSG9zdEltcGwsIHNvCisgICAgLy8gdGhhdCB3 ZSBjYW4gZm9yY2UgcGFydGlhbCBzd2FwIGVuYWJsZWQuCisgICAgQ0NTZXR0aW5ncyBzZXR0aW5n czsKKyAgICBzZXR0aW5ncy5wYXJ0aWFsU3dhcEVuYWJsZWQgPSB0cnVlOworICAgIE93blB0cjxD Q0xheWVyVHJlZUhvc3RJbXBsPiBsYXllclRyZWVIb3N0SW1wbCA9IENDTGF5ZXJUcmVlSG9zdElt cGw6OmNyZWF0ZShzZXR0aW5ncywgdGhpcyk7CisgICAgbGF5ZXJUcmVlSG9zdEltcGwtPmluaXRp YWxpemVMYXllclJlbmRlcmVyKGNvbnRleHQpOworICAgIGxheWVyVHJlZUhvc3RJbXBsLT5zZXRW aWV3cG9ydFNpemUoSW50U2l6ZSg1MDAsIDUwMCkpOworCisgICAgQ0NMYXllckltcGwqIHJvb3Qg PSBuZXcgRmFrZURyYXdhYmxlQ0NMYXllckltcGwoMSk7CisgICAgcm9vdC0+c2V0QW5jaG9yUG9p bnQoRmxvYXRQb2ludCgwLCAwKSk7CisgICAgcm9vdC0+c2V0Qm91bmRzKEludFNpemUoNTAwLCA1 MDApKTsKKyAgICByb290LT5zZXREcmF3c0NvbnRlbnQodHJ1ZSk7CisgICAgbGF5ZXJUcmVlSG9z dEltcGwtPnNldFJvb3RMYXllcihhZG9wdFB0cihyb290KSk7CisKKyAgICAvLyBGaXJzdCBmcmFt ZTogaWdub3JlLgorICAgIGxheWVyVHJlZUhvc3RJbXBsLT5kcmF3TGF5ZXJzKCk7CisgICAgbGF5 ZXJUcmVlSG9zdEltcGwtPnN3YXBCdWZmZXJzKCk7CisgCisgICAgLy8gU2Vjb25kIGZyYW1lOiBu b3RoaW5nIGhhcyBjaGFuZ2VkIC0tLSBzbyB3ZSBzb3VsZG4ndCBwdXNoIGFueXRoaW5nIHdpdGgg cGFydGlhbCBzd2FwLgorICAgIGxheWVyVHJlZUhvc3RJbXBsLT5kcmF3TGF5ZXJzKCk7CisgICAg bGF5ZXJUcmVlSG9zdEltcGwtPnN3YXBCdWZmZXJzKCk7CisgICAgRVhQRUNUX1RSVUUocGFydGlh bFN3YXBUcmFja2VyLT5wYXJ0aWFsU3dhcFJlY3QoKS5pc0VtcHR5KCkpOworCisgICAgLy8gVGhp cmQgZnJhbWU6IHZpc2liaWxpdHkgY2hhbmdlIC0tLSBzbyB3ZSBzaG91bGQgcHVzaCBhIGZ1bGwg ZnJhbWUgd2l0aCBwYXJ0aWFsIHN3YXAuCisgICAgbGF5ZXJUcmVlSG9zdEltcGwtPnNldFZpc2li bGUoZmFsc2UpOworICAgIGxheWVyVHJlZUhvc3RJbXBsLT5zZXRWaXNpYmxlKHRydWUpOworICAg IGxheWVyVHJlZUhvc3RJbXBsLT5kcmF3TGF5ZXJzKCk7CisgICAgbGF5ZXJUcmVlSG9zdEltcGwt PnN3YXBCdWZmZXJzKCk7CisgICAgSW50UmVjdCBhY3R1YWxTd2FwUmVjdCA9IHBhcnRpYWxTd2Fw VHJhY2tlci0+cGFydGlhbFN3YXBSZWN0KCk7CisgICAgSW50UmVjdCBleHBlY3RlZFN3YXBSZWN0 ID0gSW50UmVjdChJbnRQb2ludDo6emVybygpLCBJbnRTaXplKDUwMCwgNTAwKSk7CisgICAgRVhQ RUNUX0VRKGV4cGVjdGVkU3dhcFJlY3QueCgpLCBhY3R1YWxTd2FwUmVjdC54KCkpOworICAgIEVY UEVDVF9FUShleHBlY3RlZFN3YXBSZWN0LnkoKSwgYWN0dWFsU3dhcFJlY3QueSgpKTsKKyAgICBF WFBFQ1RfRVEoZXhwZWN0ZWRTd2FwUmVjdC53aWR0aCgpLCBhY3R1YWxTd2FwUmVjdC53aWR0aCgp KTsKKyAgICBFWFBFQ1RfRVEoZXhwZWN0ZWRTd2FwUmVjdC5oZWlnaHQoKSwgYWN0dWFsU3dhcFJl Y3QuaGVpZ2h0KCkpOworfQorCiB9IC8vIG5hbWVzcGFjZQo=