On Tue Dec 5 01:23:40 2023 +0000, Alfred Agrell wrote:
I don't know what Microsoft's intention is or what's officially supported, but a quick WINEDEBUG=trace+quartz tells me that Kirikiri does, in fact, call ChangeD3DDevice while the graph is connected but stopped. It's the last thing it does before IMediaControl::Run(). (Kirikiri doesn't pause the graph, it just goes directly to Run.) Kirikiri's source code also shows that the function is called if IDirect3DDevice9::Present returns D3DERR_DEVICELOST; Present() is only plausible while paused or running, though I don't know if that code path was ever tested. (Also rebased this thing. No other changes.)
Fair enough, I can only assume they avoid the race somehow else then, e.g. by always happening to wait the few ms necessary to ensure the asynchronous reconnect completes. It certainly wouldn't surprise me.
In any case I think the best thing we can do for the tests is to not test that case. We want the tests to pass consistently, and experience has taught me that the only way to achieve that is to never rely on Sleep().
The stopped case should be interesting enough by itself anyway.