According to the documentation the proper way to handle input in a store app is to create a CoreIndependentInputSource from another thread by calling swapChainPanel.CreateCoreIndependentInputSource(). This gives you low latency input in case of a busy UI thread.
Once you create a CoreIndependentInputSource, touch visual feedback is visible again. Even if you disabled it using
auto pointerVisualizationSettings = Windows::UI::Input::PointerVisualizationSettings::GetForCurrentView();
pointerVisualizationSettings->IsContactFeedbackEnabled = false;
pointerVisualizationSettings->IsBarrelButtonFeedbackEnabled = false;
It's not about aesthetics, Visualfeedback kills performance, the framerate in games drops by half, which is ironic if you think that's the kind of apps CoreIndependentInputSource was created for in the first place. Devices with touch input are the ones that suffer the most from this bug since they come with weak GPUs. Devs have to chose either low responsiveness or low performance.
CoreIndependentInputSource has it's own Dispatcher, does that mean it has it's own HWND/message queue?
Maybe that's the cause of the bug, PointerVisualizationSettings.GetForCurrentView() is tied to the main Window.
If you try to call "PointerVisualizationSettings.GetForCurrentView().IsContactFeedbackEnabled = false;" from the input thread it fails with an exception.
I got the _hWnd from CoreIndependentInputSource.Dispacher using the VS debug inspector and then called TryDisableWindowsVisualFeedback() as seen here http://stackoverflow.com/questions/27550373/disable-touch-visual-feedback-on-windows-8-1-programmatically-desktop-app
The visual feedback was disabled!
However, live code has no access to that hWnd. All helpful Win32 apis fail one way or another (GetActiveWindow(), GetProccessId(), EnumWindows(), etc).
Kastellanos Nikos commented
For example, at 'LowLatencyInput' sample.
It's supposed to disable touch visualfeedback but it doesn't.
do they allow one to customize the touch visual feedback (preferably programmatically AND at the app level, not at user level)? that could be a sideways approach to make it disappear or at least consume less resources