@reuk, Since commit
, I’m getting an assert on launching any StandAlone Plugin build in debug mode. This happens when the first frame should be presented. This is from the Juce GainPlugin example without any modifications. I’m running the latest Windows 11 & the latest VS on a 890M iGPU.
Update: a release build just hangs and never succeeds to present a frame 
… and I get the same assert on a Nvidia RTX GPU. If I continue to execute on that machine, things seem to be able to recover.
Can you confirm if you are seeing the same issue using the develop branch? We might have fixed this yesterday.
yep on the latest develop branch on commit #83dc660a306388302f24788695d29d827408e6f3 also. What commit should have fixed it?
Oh and btw. It does not happen if I build ProJucer. I only see it on Standalone Plugin builds so far.
Ah, this was the change I was hoping might be the fix:
I shall investigate
Are you seeing the issue on 2 different machines or a laptop with dedicated and iGPU?
Two different machines. A laptop with a Radeon iGPU and a Desktop with a Ryzen CPU without iGPU and a Nvidia RTX GPU, both machines are running Windows 11.
There is a difference I see. On the NVidia GPU the assert is only hit once on the first frame, while on the Radeon iGPU it happens for every frame.
So a release build does work on NVidia, but on the Radeon iGPU I only get a blank window.
As my Radeon iGPU (890M) is quite new, maybe it’s an immature driver issue on that one. On the NVidia RTX I’m running the latest “game-ready” drivers from a few weeks ago.
I just tested this on a few machines (xps laptop, integrated graphics, windows 11; desktop PC, integrated graphics, windows 11; desktop PC, NVidia GT 1030, windows 10) and couldn’t get the assertion to fire on any of those.
Please could you try making the following changes in modules/juce_graphics/native/juce_DirectX_windows.h:
| D3D11_CREATE_DEVICE_DEBUG at the end of the statement to enable D3D debug mode.D2D1_DEBUG_LEVEL_NONE to D2D1_DEBUG_LEVEL_INFORMATION to enable D2D debug mode.Then, re-run the program and inspect the console/debug output. The runtime should print a diagnostic message to explain the error. If you can provide the full text of the error, that will help us to debug further.
Thank you for the instructions. I changed the two lines and the problem seemed gone. Then I went back to the original state, did a rebuild and the problem was there again. So I changed the lines again, did a rebuild once more and then I got:
onecoreuap\windows\frameworkudk\warppal.cpp(783)\Microsoft.Internal.WarpPal.dll!00007FF87B65EE4C: (caller: 00007FF87C3E3FDE) ReturnHr(1) tid(4dcc) 80004002 No such interface supported
DXGI ERROR: IDXGISwapChain::Present: Partial Presentation (using scroll or dirty rects) is not valid until first submitting a regular Present without scroll or dirty rects. Otherwise, the preserved back-buffer data would be uninitialized. [ MISCELLANEOUS ERROR #105: ]
JUCE Assertion failure in juce_Direct2DHwndContext_windows.cpp:322
A breakpoint instruction (__debugbreak() statement or a similar call) was executed in GainPlugin.exe.
This is all on my laptop with Radeon iGPU.
Hmm, I’m really puzzled now. It seems to sometimes work for some reason and fail at other times.
Maybe it’s best to wait and see whether someone else is affected by this as well.
I think you found the problem; the renderer needs to fill the entire window once before trying to just paint part of the window.
Matt
@matt, I tried your patch (on my Radeon 890M) laptop and it fixes the problem! No more jassertquiet. Thanks!
With the debug output enabled, I still get one message, but I guess that’s unrelated:
onecoreuap\windows\frameworkudk\warppal.cpp(783)\Microsoft.Internal.WarpPal.dll!00007FF87B65EE4C: (caller: 00007FF87C3E3FDE) ReturnHr(1) tid(47ec) 80004002 No such interface supported`
WARP is the software renderer built into Windows.
Maybe the JUCE renderer is instantiating that; it should probably only instantiate physical hardware.
Matt
Glad it worked!
Matt
Thanks for trying Matt’s patch. I’ve put together a slightly more minimal change that may fix the issue. I’d be interested to know if it works for you:
0001-WIP-Avoid-using-dirty-rects-when-painting-full-frame.patch (2.5 KB)
@reuk, I tried your patch and it also solves the issue for me, thanks!
Thanks for confirming, that’s merged now:
Thank you! btw. as it happened to me on two machines, but not all the time, I guess it is related to how I launch the debug standalone executable, not the GPU type. Both machines were running windows with high scaling ratios and maybe I switched windows/apps during compilation/launch.
