(11.1-beta2) Compositor not always releasing DXGI mutex in Image interop

[amwx]

Describe the bug

Using the GPU interop composition stuff, attempting to update a shared surface via _surface.UpdateWithKeyMutexAsync() will sometimes not release the mutex leading to deadlock. The Task that fires for completion returns sucessfully but the mutex value is never reset thus my call to AquireSync deadlocks.

This issue only occurs in beta2, beta 1 works as expected.

To Reproduce

Repro project: It is just a simple draw a rectangle with the mouse. Make quick movements with the mouse and the app will freeze at the AcquireSync call on the app side. If you switch back to beta1, it will all work fine

Demo.zip

Expected behavior

No response

Avalonia version

11.1-beta2

OS

Windows

Additional context

No response

[kekekeks]

This issue only occurs in beta2, beta 1 works as expected.

481 changed files with 15,759 additions and 6,408 deletions.

Could you bisect a bit further?

[amwx]

This is what I got

eee71a62718653583f6b2e96f873a8f945701eaf is the first bad commit
commit eee71a62718653583f6b2e96f873a8f945701eaf
Author: Steven Kirk <grokys@users.noreply.github.com>
Date:   Sat Apr 20 03:29:12 2024 +0300

    Fix input starvation issues on resource-constrained devices. (#15137)

    * Use 0.2 seconds for input starvation cutoff.

    1 second was too long when running on resource-constrained devices.

    * Allow input starvation code to run.

    Using `ScheduleRender(true)` here prevented the input starvation code from running.

    * Add DispatcherOptions.

    And allow setting the input starvation timeout there.

 src/Avalonia.Base/Media/MediaContext.Compositor.cs |  2 +-
 src/Avalonia.Base/Media/MediaContext.cs            | 13 ++++++++++---
 src/Avalonia.Base/Threading/DispatcherOptions.cs   | 21 +++++++++++++++++++++
 3 files changed, 32 insertions(+), 4 deletions(-)
 create mode 100644 src/Avalonia.Base/Threading/DispatcherOptions.cs

Edit: Adding this seems to make the deadlock less likely to happen (though it still can):
new DispatcherOptions { InputStarvationTimeout = TimeSpan.FromSeconds(10) }

[kekekeks]

That particular PR has changed the way composition batches are being scheduled on the UI thread.

Are you sure that you aren't trying to call _mutex->AcquireSync before the latest UpdateWithKeyMutexAsync is completed?

[kekekeks]

I. e. the input starvation logic can enforce all input to be handled before scheduled render pass. So if you aren't awaiting the latest task it would indeed result in a deadlock once that kicks in.

[amwx]

Ok, I've gotten it fixed by ensuring the Task completed before attempting to render again.

I used the GpuInterop sample as reference for this and on the surface, the only place the LastPresent task is used in the sample is in the Dispose method, I had to go hunting elsewhere to find that it is actually checked before another pass.