please provide examples of using DirectX and SwapChainPanel in c++/Winrt for desktop app.

[ifgotmoney]

Hello community,

I'm trying to port an example code of DirectX from UWP to Desktop APP in C++, but always failure in the porting from UWP/WRL to desktop/Winrt. I searched online but haven't found any example code that is really written in C++/WinRT for WinUI3 desktop APP.

also there is not template for using DirectX with C++/Winrt and Winui3 for desktop app (not UWP)

Can anyone please provide some examples of using directX and swapchainpanel with C++/Winrt for desktop apps (not for UWP)

[ifgotmoney]

hi everyone, is there any suggestion for this?

I just tried many times but got nothing than debug errors.

Is there anyone really using C++/WinRT and DirectX for Desktop Apps (not for UWP)? Just get stuck here for 1 month. I have tried win2D but also with problems, so I turned to directX + SwapChainPanel, but seems almost all the examples are written for UWP/C++/CX.

[DarranRowe]

I have no issues working with Direct3D/Xaml interop myself.
The thing that I have found is that since C++/CX is a projection the same as C++/WinRT, it is easy enough to convert between them. Also, since the majority of the programming is Direct3D related, this has very little to do with C++/WinRT/Xaml/UWP/C++/CX or anything like that. This means that it really should be easy.

For the SwapChainPanel, the basics should be as follows.

Initialise DXGI, Direct3D and anything else required. This is framework independent. This is also just the regular D3D initialisation. Create the D3D11 device and device context or the D3D12 command queue and the DXGI swap chain. You just have to remember to create the swap chain for composition.

Query the SwapChainPanel for the ISwapChainPanelNative interface. This is framework dependent and you can find the interface in the microsoft.ui.xaml.media.dxinterop.h header. You then call SetSwapChain to set the SwapChainPanel's swap chain to the one you created in the D3D initialisation.

Finally, you start off the rendering loop. This doesn't have to be framework dependent at all. As long as it does the drawing followed by the swap chain present then it works. It also can be on a completely separate thread if you remember to enable this.

[castorix]

Is there anyone really using C++/WinRT and DirectX for Desktop Apps (not for UWP)? Just get stuck here for 1 month. I have tried win2D but also with problems, so I turned to directX + SwapChainPanel, but seems almost all the examples are written for UWP/C++/CX.

I use SwapChains with WinUI 3/Direct2D and C# + P/Invoke and it works fine (I cannot use C++/WinRT because it takes hours to compile on my old PC)
In C++/WinRT, there was this sample with a SwapChainPanel from asklar : MainWindow.xaml.cpp

[ifgotmoney]

thank you, guys. yes it seems migrating from C++/WRL/UWP to C++/WinRT/Desktop App is quite simple. I also thought so before starting.

however, I have just interpreted the sample code for UWP to Desktop, but It can't run successfully.

always failure for below code interpreting

    // Associate swap chain with SwapChainPanel
    // UI changes will need to be dispatched back to the UI thread
    m_swapChainPanel->Dispatcher->RunAsync(CoreDispatcherPriority::High, ref new DispatchedHandler([=]()
    {
        // Get backing native interface for SwapChainPanel
        ComPtr<ISwapChainPanelNative> panelNative;
        DX::ThrowIfFailed(
            reinterpret_cast<IUnknown*>(m_swapChainPanel)->QueryInterface(IID_PPV_ARGS(&panelNative))
            );

        DX::ThrowIfFailed(
            panelNative->SetSwapChain(m_swapChain.Get()));
    }, CallbackContext::Any));

what I do is sth like below:
m_swapChainPanel.DispatcherQueue().TryEnqueue(
Microsoft::UI::Dispatching::DispatcherQueuePriority::High,
this {
auto panelNative = m_swapChainPanel.as();
winrt::check_hresult(panelNative->SetSwapChain(m_swapChain.get()));

            }
        );

and I saw
Exception thrown: read access violation. **ptr** was 0xFFFFFFFFFFFFFFFF.

also see errors when translate below code
// Create a task that will be run on a background thread.
auto workItemHandler = ref new WorkItemHandler([this](IAsyncAction ^ action)
{
// Calculate the updated frame and render once per vertical blanking interval.
while (action->Status == AsyncStatus::Started)
{
critical_section::scoped_lock lock(criticalSection);

        // Block this thread until the swap chain is finished presenting. Note that it is
        // important to call this before the first Present in order to minimize the latency
        // of the swap chain
        deviceResources->WaitOnSwapChain();
        Render();
        deviceResources->Present();
    }
});

and see errors when translate below code
//Block the current thread until the swap chain has finished presenting.
void DX::DeviceResources::WaitOnSwapChain()
{
DWORD result = WaitForSingleObjectEx(
m_frameLatencyWaitableObject,
INFINITE, // Infinite timeout (shouldn't ever occur)
true
);
}

Do I miss something important when port the sample code from UWP to Desktop APP??

[DarranRowe]

Unfortunately, without knowing what you have or haven't done, it is difficult to say anything. But for some guidance.

When you see unexpected weird pointer values, you really should be thinking one of three things. Uninitialised variables, use after free or a race condition.

For the second error, since you don't show what your translated code is, or give any information on any errors you are getting, then it is impossible to say anything.

For the third error, this is an interesting case because of how simple the code is. This code does allow for a certain degree of speculation because of how simple it is. First, since you didn't specify which errors you see, I am currently assuming that it is a runtime error. The reasoning behind this is simple. WaitForSingleObjectEx is a Windows API function. This means that if it was a compiler error then your environment is just outright broken. If you are seeing an error, this means that it is returning -1/0xffffffff.
This function being this simple means that the only possible thing that could be wrong is the handle it is waiting on. So, if you look in the original code and find where the handle is initialised then it is possible to see where this code could go wrong. The handle is initialised in the DeviceResources::CreateWindowSizeDependentResources member function and is initialised as follows:

m_frameLatencyWaitableObject = swapChain2->GetFrameLatencyWaitableObject();

There is a comment directly above it stating about the requirement of a certain flag, and looking at the swap chain descriptor, you see

DXGI_SWAP_CHAIN_DESC1 swapChainDesc = {0};

swapChainDesc.Width = lround(m_d3dRenderTargetSize.Width); // Match the size of the window.
swapChainDesc.Height = lround(m_d3dRenderTargetSize.Height);
swapChainDesc.Format = DXGI_FORMAT_B8G8R8A8_UNORM; // This is the most common swap chain format.
swapChainDesc.Stereo = false;
swapChainDesc.SampleDesc.Count = 1; // Don't use multi-sampling.
swapChainDesc.SampleDesc.Quality = 0;
swapChainDesc.BufferUsage = DXGI_USAGE_RENDER_TARGET_OUTPUT;
swapChainDesc.BufferCount = 2; // Use double-buffering to minimize latency.
swapChainDesc.SwapEffect = DXGI_SWAP_EFFECT_FLIP_SEQUENTIAL; // All Windows Store apps must use this SwapEffect.
//swapChainDesc.Flags = 0;
swapChainDesc.Flags = DXGI_SWAP_CHAIN_FLAG_FRAME_LATENCY_WAITABLE_OBJECT; // Enable GetFrameLatencyWaitableObject()
swapChainDesc.Scaling = DXGI_SCALING_STRETCH;
swapChainDesc.AlphaMode = DXGI_ALPHA_MODE_IGNORE;

The reason why this is very suspicious is that GetFrameLatencyWaitableObject is documented to return null if this is called on a swapchain that was created without the flag to enable it and WaitForSingleObjectEx fails if you pass in an invalid handle. If you notice, the handle isn't actually checked when GetFrameLatencyWaitableObject is called, so if you naïvely copy this and don't assert on it at the very least, then this could be one potential problem.

This analysis does actually raise a very important point though. The actual cause of an error can happen at any time before you see the error happen and it can be in a completely different function.

But as I said, this is just speculation.

[ifgotmoney]

Thank you very much @DarranRowe and wish you a good holiday season.

I have tried step by step debugging into those functions, and now I guess I find the problem. I'm not sure if something is wrong during the translation between ASTA asynchronous to STA asynchronous model, from code snippet ThreadPool::RunAsync to DispatcherQueue().TryEnqueue

but definitively the objects are not available when the code runs into below section:

original code:

void LowLatencyInputMain::StartRenderLoop()
{
    // If the animation render loop is already running then do not start another thread.
    if (renderLoopWorker != nullptr && renderLoopWorker->Status == AsyncStatus::Started)
    {
        return;
    }

    // Create a task that will be run on a background thread.
    auto workItemHandler = ref new WorkItemHandler([this](IAsyncAction ^ action)
    {
        // Calculate the updated frame and render once per vertical blanking interval.
        while (action->Status == AsyncStatus::Started)
        {
            critical_section::scoped_lock lock(criticalSection);

            // Block this thread until the swap chain is finished presenting. Note that it is
            // important to call this before the first Present in order to minimize the latency
            // of the swap chain
            deviceResources->WaitOnSwapChain();
            Render();
            deviceResources->Present();
        }
    });

    // Run task on a dedicated high priority background thread.
    renderLoopWorker = ThreadPool::RunAsync(workItemHandler, WorkItemPriority::High, WorkItemOptions::TimeSliced);
}

my interpretation:

void DxDrawingEngine::DxRenderingLoop::StartRenderLoop()
{
	// If the animation render loop is already running then do not start another thread.
	if (m_isRenderLoopRunning)
	{
		return;
	}
	if (m_renderLoopController == nullptr)
	{
		m_renderLoopController = Microsoft::UI::Dispatching::DispatcherQueueController::CreateOnDedicatedThread();
		
	}
	
	m_isRenderLoopRunning = m_renderLoopController.DispatcherQueue().TryEnqueue(Microsoft::UI::Dispatching::DispatcherQueuePriority::High, [=]() {
		while (m_isRenderLoopRunning) {
			OutputDebugString(L"Entering Rending Loop \n");
			//Concurrency::critical_section::scoped_lock lock(m_criticalSection);
			//EnterCriticalSection(&cs);
			//std::scoped_lock lock(m);
			//EnterCriticalSection(&cs);
			**m_deviceResources**->WaitOnSwapChain();
			//EnterCriticalSection(&m.lock());
			this->Rendering();
			**m_deviceResources**->Present();
			//LeaveCriticalSection(&cs);
			//m_criticalSection.unlock();
		}
	});
	
}

the object address of m_deviceResources (m_ptr) is 0x000df234234.... something like this before entering DispatcherQueue().TryEnqueue.
but inside the lambda function, the address of m_deviceResources (m_ptr) becomes 0xddddddddddd...., thus I see the read access violation errors.

It is not related to swapChainDesc.Flags as in my code I also use swapChainDesc.Flags = DXGI_SWAP_CHAIN_FLAG_FRAME_LATENCY_WAITABLE_OBJECT; it should work.

I also tried change the capture list of lambda expression to this, =, &, still see the errors.

So from code snippet ThreadPool::RunAsync to DispatcherQueue().TryEnqueue is this the right way for migration?

[DarranRowe]

Well, the pointer becoming all ds like that indicates that the object that contains the m_ptr is being deleted. The CRT debug heap fills an object with the byte 0xdd when it is being freed.

But anyway, no, a dispatcher queue running on a separate thread is not a replacement for a thread pool thread. ThreadPool is documented to be supported for desktop applications, this means that just using Windows.System.Threading.ThreadPool and related things as-is is a valid operation. But IIRC, this is a little problematic support-wise for unpackaged applications. If ThreadPool itself is not possible, then the replacement would be the Windows Thread Pool API.

Also, this shouldn't be an ASTA->STA issue since the work is running on a separate thread. UWP processes would normally have auto MTA, meaning any new thread being created would be MTA by default. Desktop processes would either have COM uninitialised or auto MTA depending on if an MTA thread exists or the CoIncrementMTAUsage has been called. Secondly, Direct3D/Direct2D/DXGI is a COM like API meaning that COM doesn't have to be initialised for it to work.

[ifgotmoney]

still not find a way out.

[ifgotmoney]

thank you all very much

here just close this thread.

include "winrt/Windows.System.Threading.h" makes the threadpool class works for desktop APP.
the example code doesn't have this header file included in pch.h, but in WinUI3 for desktop we need to manually include this header file.

one more thing may be helpful to others
I found this article from microsoft regarding Asynchrony, and interop between C++/WinRT and C++/CX, it provided a way to make this pointer always alive by Derive LowLatencyInputMain from public winrt::implements<LowLatencyInputMain, winrt::Windows::Foundation::IInspectable>, and then use [this, self=get_strong] in the capture list to make everything working. by this method, the dispatcherqueue also works.