[BUG]: SetThreadDpiAwarenessContext not working with COINIT_MULTITHREADED

[ReinholdH]

Windows Version

Windows 11, 24H2,OS Build 26100.3476)

Service Installation Method

GitHub

SDK version, if appropriate

MIDI_Preview1.0.3-preview-11.250228-237

Location

Application using Windows MIDI Services SDK (MIDI 2.0)

Type of bug

Application not working as expected

Steps to reproduce

• Use a multi resolution monitor environment.
• Open Notation Composer (as privately provided to @Psychlist1972)
• Open a file
• Move the open dialog from the 175% resolution monitor to the 100% resolution monitor

Expected behavior

SetThreadDpiAwarenessContext to work with winrt::init_apartment();
(but not only to work with winrt::init_apartment(winrt::apartment_type::single_threaded);)
or alternatively
Windows MIDI Services work with winrt::init_apartment(winrt::apartment_type::single_threaded);

Additional notes

Notation Software's apps are fully DPI V2 aware. The event WM_DPICHANGED is handled everywhere with appropriate actions to scale for the current used monitor. However, some dialogs like CFileDialog and it's inherited classes do not receive aWM_DPICHANGED. In order to deal with that SetThreadDpiAwarenessContext(DPI_AWARENESS_CONTEXT_UNAWARE_GDISCALED); is used temporarily to achieve a proper DPI scaling when moving dialogs between monitors of different DPI resolutions.

Windows MIDI Services requires winrt::init_apartment(); where apartment_type::multi_threaded is underneath. winrt::init_apartment(); requires that the complete app uses COINIT_MULTITHREADED throughout.

When setting the complete app to COINIT_MULTITHREADED the call SetThreadDpiAwarenessContextdoes not work any longer and dialogs are not properly scaled. See

This is an example where a dialog was opened on a 175% resolution monitor and moved to a 100% monitor.

[Psychlist1972]

Have you tried your app with Windows MIDI Services with single_threaded? As per the previous discussion, it's not our preferred threading model as it will require a lot of marshalling of callbacks, but it should work. It's just not something we do any significant testing with at the moment because all the apps using it have a separation between MIDI/Audio threads and UI threads.

The typical approach here is to have a separate UI thread vs workers. The COM and WinRT init calls are per-thread.

Pete

[ReinholdH]

Pete,

Thanks for the immediate response. At a first glance single_threaded works. We also have the runtime consuming parts of the initialization in a separate thread but winrt::init_apartment(); is not yet in there. Let me check it if winrt::init_apartment(); can be located in that thread as well. If possible I would really handle everything as per your advice. I am going to report my findings here asap in the next days.

Reinhold

[ReinholdH]

Pete,

I was able to separate winrt::init_apartment(); and UI handling into separate threads where MIDI initialization runs multi-threaded and UI thread single-threaded. With this design change the reported issue here and the 'Microsoft Print to PDF' reported recently is resolved.

IMHO the lessons learned are:

• Fortunately, most of the thread separating work was done before where we could benefit from. Otherwise it would have been a major architectural change for a legacy app.
• Without running MIDI initialization in a separate thread, MIDI initialization needs to be started with winrt::init_apartment(apartment_type::single_threaded). Otherwise there is a high risk for an app that features won't work as before (like 'Microsoft print to PDF', SetThreadDpiAwarenessContext and potentially other stuff ?? I do not know)
• Overall, I believe that Microsoft needs to run tests with winrt::init_apartment(apartment_type::single_threaded) as well
• I hope that this finding has no implication for a WinMM app which will run unchanged on the new MIDI architecture
• Documentation need to be enhanced. e.g. here

From my perspective this issue can be closed. It is resolved for our software but may be worth to think about the bullet points.

Reinhold

[Psychlist1972]

Thanks Reinhold.

Are you sure the DPI Awareness function doesn't work in multi-threaded, and it's not that there's something else in the code preventing that? Usually a restriction like that on an in-box API would be documented. (I'd expect any similar limitation in the print to PDF to also be documented)

edit: Searching around, I see no mention of any threading limitations for SetThreadDpiAwarenessContext. If you don't have a small repro project for that, I'll add that to my todo list to verify that there's a limitation there.

For MIDI, we actually removed internal use of WinRT from the WinMM API wdmand2.drv code specifically because we couldn't guarantee the thread had been COM initialized, and don't want to do that internally for all the reasons you can imagine. Also, the WinMM API doesn't talk to the SDK, but instead talks to the RPC endpoints for the service, so no concern there with mixing and matching.

C++/WinRT itself takes care of marshalling when needed, so the SDK should work fine in either model. But, again, additional marshalling could mean a slight performance hit primarily on incoming message callbacks (which come from an RPC thread and would need to be marshalled) so we recommend apartment there.

I'll add some basic tests (for some specific areas of potential concern) and update the docs, but I don't plan to be exhaustive there; the threading information is described in the C++/WinRT docs which I'll link to.