How to migrate this DirectX example to winui3 desktop from UWP.

[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)

The error comes from the threadpool function migration.
in this example the source code looks like this:

but when I using DispatcherQueueController instead, I always see access violation errors. what's the right way to translate those code for WinUI3 desktop with C++/WinRT??

m_renderLoopController=winrt::Microsoft::UI::Dispatching::DispatcherQueueController::CreateOnDedicatedThread();
m_renderLoopController.DispatcherQueue().TryEnqueue(this {
.......

[DarranRowe]

As I said in your question in the Windows App SDK discussions, the dispatcher queue is NOT a proper replacement for a thread pool. You want to be using the thread pool, either through the ThreadPool runtime class or through the Windows Thread Pool API.
I also have to ask at this point, since this is a capturing lambda, have you confirmed that this isn't a lambda lifetime issue? This is a general C++ knowledge issue. The simplest way to test that out would be to make the lambda into a member function.

[ifgotmoney]

Thank you @DarranRowe, while I take those part outside the lambda function, it works, so I think it is a lambda lifetime issue here,
I tried
'''
TryEnqueue(self=weak_from_this().lock() {
'''
but doesn't change the result.

for the item deviceResource I found a solution: use weak_ptr can sucessfully pass into lambdas.

but for the criticalSection variable, and this pointer I haven't found a way yet.

I also tried [CreateThreadpoolWait] of Thread Pool API.

sorry to bother you too much, I'm a chemical process engineer here not a professional programmer, so may lack of some basic knowledge that a professional one should know.

I plan to build a software that can draw some simple sketches (similar to VISIO but simple than that) I have tried Win2D but there's some lag/latency on the drawing items when drag & move mentioned in this issue, so I want to check that example I mentioned above (independent thread rendering & independent thread input to reduce the latency) however that example was for UWP.

by the way, the Win2D repo seems has been deprecated already.

[ifgotmoney]

I plan to build a software that can draw some simple sketches (similar to VISIO but simple than that) I have tried Win2D but there's some lag/latency on the drawing items when drag & move

Don't you want to use C# instead of C++ ? I program in C/C++ for decades, but C# + Direct2D in WinUI 3 or Winforms is a lot simpler than C+/WinRT and performances are perfect from my tests (even in VB on my old PC without real GPU (Intel(R) HD Graphics))

.net makes everything open source, no matter you want or you dont want to.

[ifgotmoney]

Well, I spend the last few days gradually doing a little port of this. It is not perfect by any means, since it currently doesn't release any of the resources and I think it has a race condition on exiting, but that particular function that you mentioned in your original post was very literal.

void LowLatencyInputMain::StartRenderLoop()
{
	if (renderLoopWorker != nullptr && renderLoopWorker.Status() == winrt::Windows::Foundation::AsyncStatus::Started)
	{
		return;
	}
	auto workItemHandler = winrt::Windows::System::Threading::WorkItemHandler([this](const winrt::Windows::Foundation::IAsyncAction &action)
		{
			while (action.Status() == winrt::Windows::Foundation::AsyncStatus::Started)
			{
				Concurrency::critical_section::scoped_lock lock(criticalSection);

				deviceResources->WaitOnSwapChain();
				Render();
				deviceResources->Present();
			}
		});

	renderLoopWorker = winrt::Windows::System::Threading::ThreadPool::RunAsync(workItemHandler, winrt::Windows::System::Threading::WorkItemPriority::High, winrt::Windows::System::Threading::WorkItemOptions::TimeSliced);
}

The WorkItemHandler instance holds a copy of the lambda in this case, and the renderLoopWorker holds a reference to everything. There are some things which does require a bit more of a creative interpretation to get it to work, but this isn't one of them. I left the full namespaces in to show where I got things from, but I would normally use namespace aliases or using namespace.

Seems you are porting them from C++/WRL to C++/WinRT??
the Windows::System::Threading namespace doesn't exist in WinUI3 for Desktop. that's my problem

[DarranRowe]

There is no difference between general C++/WinRT and WinUI 3. The project that I used was made out of the WinUI 3 in Desktop project template too. But from what you stated, let me give you a hint.

// Copyright (c) Microsoft Corporation and Contributors.
// Licensed under the MIT License.

#pragma once
#include <windows.h>
#include <unknwn.h>
#include <restrictederrorinfo.h>
#include <hstring.h>

// Undefine GetCurrentTime macro to prevent
// conflict with Storyboard::GetCurrentTime
#undef GetCurrentTime

#include <winrt/Windows.Foundation.h>
#include <winrt/Windows.Foundation.Collections.h>
#include <winrt/Windows.ApplicationModel.Activation.h>
#include <winrt/Windows.Graphics.Display.h>
#include <winrt/Windows.Storage.h>
#include <winrt/Windows.Storage.Streams.h>
#include <winrt/Windows.System.h>
//This header includes the definition for the Windows.System.Threading namespace
#include <winrt/Windows.System.Threading.h>

#include <winrt/Microsoft.UI.Composition.h>
#include <winrt/Microsoft.UI.Input.h>
#include <winrt/Microsoft.UI.Windowing.h>
#include <winrt/Microsoft.UI.Xaml.h>
#include <winrt/Microsoft.UI.Xaml.Automation.Peers.h>
#include <winrt/Microsoft.UI.Xaml.Controls.h>
#include <winrt/Microsoft.UI.Xaml.Controls.Primitives.h>
#include <winrt/Microsoft.UI.Xaml.Data.h>
#include <winrt/Microsoft.UI.Xaml.Input.h>
#include <winrt/Microsoft.UI.Xaml.Interop.h>
#include <winrt/Microsoft.UI.Xaml.Markup.h>
#include <winrt/Microsoft.UI.Xaml.Media.h>
#include <winrt/Microsoft.UI.Xaml.Navigation.h>
#include <winrt/Microsoft.UI.Xaml.Shapes.h>
#include <winrt/Microsoft.UI.Dispatching.h>
#include <wil/cppwinrt_helpers.h>
#include <wil/result.h>

#include <wrl.h>
#include <d3d11_4.h>
#include <d2d1_3.h>
#include <dxgi1_6.h>
#include <dwrite_3.h>
#include <wincodec.h>
#include <DirectXColors.h>
#include <DirectXMath.h>

#include <ppltasks.h>
#include <pplawait.h>
#include <concrt.h>

That is the full contents of the pch.h file for my project. There is nothing stopping you from including extra headers here.

[castorix]

Don't you want to use C# instead of C++ ? I program in C/C++ for decades, but C# + Direct2D in WinUI 3 or Winforms is a lot simpler than C+/WinRT and performances are perfect from my tests (even in VB on my old PC without real GPU (Intel(R) HD Graphics))

.net makes everything open source, no matter you want or you dont want to.

I don't understand what you mean...
I just said that instead of writing code in C++/WinRT, it is a lot easier/faster to use C#/Direct2D/PInvoke (the syntax is easier to write/read)

[ifgotmoney]

@DarranRowe thank you very much, your solution works!
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.

@castorix what I mean is the .net platform produce IL code rather than machine code, this give other one a chance to get your source code. Native C++ will not 100% percent protect your source code, but apparently it makes the reverse engineering harder.