1

I got stuck at this basic matter. I can't find any other way to obtain input but through CoreWindow class (handling KeyDown/KeyUp/PointerMoved events or calling GetKeyState in the loop). I thought that I had to deal with input device directly, but it turns out that interactions with generic HID devices are blocked for UWP applications. There is also a "low latency" sample among UWP samples, that uses some twisted method through creating dedicated XAML control, but it seems more like a method to coexist with XAML rendering loop while I'm dealing with non-xaml application.

Maybe someone knows a good workaround for this?

dodo951
  • 438
  • 4
  • 8
  • What's wrong with Raymond Chen's code sample? This is someone that knows what they are doing. And if you need a workaround for *"this"*, it's helpful if you explained precisely, what *"this"* is. – IInspectable Feb 02 '17 at 13:46
  • 1
    That code sample uses SwapChainPanel XAML control with attached CoreIndependentInputSource class instance that allows to receive input events in background thread. It's just a way to coexist with XAML event processing and can not be used in non-XAML applications. And as I explained precisely, "this" is avoiding CoreWindow events/methods as they can hardly be considered a "low latency input". – dodo951 Feb 02 '17 at 21:11
  • Nothing in the [CoreIndependentInputSource](https://msdn.microsoft.com/library/windows/apps/dn298460) documentation insists, that this can only be used in a XAML application. What am I missing? – IInspectable Feb 02 '17 at 21:17
  • 1
    From Remarks section: "Create an instance of this class by calling SwapChainBackgroundPanel::CreateCoreIndependentInputSource or SwapChainPanel::CreateCoreIndependentInputSource." So basically it can only be used with SwapChainPanel XAML control. – dodo951 Feb 02 '17 at 21:32
  • What is your threshold for "low latency"? And just to be sure: Did you measure the `CoreWindow` events to know they're not fast enough, or is it an assumption? – Peter Torr - MSFT Feb 22 '17 at 02:31
  • There are two issues with uwp events: (1) each event is a COM object, basically this whole event system just adds 6 layers on top of WndProc to the call stack and at least one heap allocation; (2) they can be received only in main thread; typically i want to receive input messages in background thread and handle other window messages in main thread along with doing DXGI stuff, mostly swap chain resizing / presenting. The overhead of UWP abi is obviously not good, but waiting all the time to present a frame is the main problem. – dodo951 Feb 23 '17 at 15:06
  • Keyboard input events seem to have about 30 extra stack levels. And yes, simply running UWP event loop is considerably slower compared to good old message proc. It causes up to 5-8% cpu core load compared to ~1%. – dodo951 Feb 23 '17 at 15:29
  • Low Latency sample also only seems to cover mouse, not keyboard. – Andy Krouwel Dec 15 '17 at 22:48
  • I'd also like an answer to this question, in relation to CoreWindow apps. – Gavin Williams Dec 07 '20 at 22:25

0 Answers0