Precision TouchPad
It's a TouchPad Specification in which TouchPad sends the raw touchpad data to Windows itself. Windows is responsible for reading the input and processing the gestures.
My Problem
I need to find absolute position of the finger on the touchpad, That is NOT the mouse location on the screen
Related
When resizing down in DirectX I noticed a flicker along the bottom/right edges.
If you fix the size of the swapchain (in red), and set the win32 background to green you will get the following on a resize down:
It appears that the window size lags behind the mouse position ("Drag Rectangle") but the area DirectX fills (in red and black) matches the Drag Rectangle, with the remainder to be painted with the window background color (green).
The DirectX Utility Toolkit (DXUT) didn't have this problem. Experimenting with their settings I found that setting DXGI_SWAP_CHAIN_DESC::SwapEffect = DXGI_SWAP_EFFECT_DISCARD would just paint the screen green (the window background color) during a sizemove. I assume that DXUT has their own special handling for when win32 enters a modal sizemove loop in order to display DirectX content during a sizemove.
DXGI_SWAP_EFFECT_DISCARD is part of the old blit mode presentation model. Notably it cant have DXGI_SWAP_CHAIN_DESC1::Scaling = DXGI_SCALING_NONE the scaling must be stretched to the window size. So my best guess is this behavior is due to the implementation of the flip presentation model (it flips a rectangle too small (black) and then covers by painting the rest green).
Does anyone know how to stop the win32 background from showing?
Edit:
Thanks to IInspectable! I can confirm the WS_EX_NOREDIRECTIONBITMAP extended style works: it stops the artifact from the win32 background showing
I reproduced the exact same behavior when using CreateSwapChainForComposition() with DirectComposition as I got using CreateSwapChainForHwnd().
This means that there are two path for pixels to get to the screen. The green pixels are going through the Redirection Surface. Hence, explicitly requesting WS_EX_NOREDIRECTIONBITMAP prevents any drawing through a Redirection Surface stopping the win32 background from showing.
The other path is the flip presentation behavior which is how the red and black pixels are get displayed. Hence, not using flip presentation when resizing also stops the win32 background from being shown.
There must be a bug with DWM: when there is a Redirection Surface, the clipping to prevent the swapchain's contents extending past the window is smaller than the redirection surface allowing it to be seen along the bottom/right edges.
There are two observations of interest:
when using WS_EX_LAYOUTRTL or manually positioning a IDCompositionVisual to the right edge of the screen with GetClientRect(), the swapchains contents are correctly position, but still clipped.
when using WS_EX_NOREDIRECTIONBITMAP the window`s nonclient area lines up with the contents of the swapchain rather than the swapchains contents being clipped
These observations would seam to imply that the cause of the issue is that DWM is using it's prefered size for the window size sometimes and the size of the redirection surface othertimes.
I'm developing a game in Cocoa, and I want to rotate the camera when the user moves the mouse, and the screen is limiting the camera movement. I hid the mouse cursor, but I want to listen when the physical mouse moves, not when the mouse cursor moves. I've heard about IOKit but that seems to be too low level. If it is any high-level way to do that, then how? And else, how do I use IOKit.
When you hide the cursor, call CGAssociateMouseAndMouseCursorPosition(FALSE). That will make it so that mouse movement does not move the cursor.
You will continue to get NSEventTypeMouseMoved, NSEventTypeLeftMouseDragged, NSEventTypeRightMouseDragged, and NSEventTypeOtherMouseDragged events as the mouse is moved (depending on whether buttons are pressed during the move). Because the cursor isn't moving, the locationInWindow won't be meaningful. It will continue to report the last location from when you disassociated the cursor from the mouse. However, the deltaX and deltaY properties will indicate how far and in what direction the mouse moved.
I have a tablet with a stylus, in normal operation it's easy to draw and figure out where the stylus is since hardware feeds the correct coordinates. Then i rotate the monitor 90 ยบ via ChangeDisplaySettingsEx API, in this situation i have to apply a translation (2nd monitor) + rotation which i'd like to avoid. Then i read about this style DS_ABSALIGN in MSDN:
Indicates that the coordinates of the dialog box are screen
coordinates. If this style is not specified, the coordinates are
client coordinates.
I'd like to draw to a DC in screen coordinates which is what i'm being feeded, not client coordinates, but defining that style doesn't make any difference.
//unaffected by the style
DrawIcon(hDevCtx, m_Point.x, m_Point.y, LoadCursor(NULL, IDC_ARROW));
Is it there any way to draw an icon in screen coordinates?
edit: finally i had no choice but to do the calculations for every turn so i close the question
The coordinates you pass to DrawIcon() depend on the kind of DC you have. For example let's say you used GetDC() to get the DC. If you pass it a window handle, the coordinates you pass to DrawIcon() will be relative to the client area of that window. If you pass 0 to GetDC() the coordinates will be relative to desktop screen. If you want to draw on desktop screen then use GetDC(0) or a better method if there is one. If you just want to convert screen coordinates to client coordinates or vice versa use ScreenToClient() or ClientToScreen()
Let's say you're holding your hand two feet away from a Mac's iSight camera and it's the thing in focus. I would like to be able to read this distance (either directly or by getting some other focus data that allows me to calculate the distance) from the iSight through some API. Anybody know if this is possible? I looked through the QTKit documentation and couldn't find anything about this.
Turns out that the iSight camera is a fixed focus camera which means there is no focal length to detect.
Is there a way to detect a blinking light as captured by the phone's camera? No filming, just turn on camera and detect any blinking lights captured.
No, without any coding this is not possible.
To program this is you would need to do this:
Use the Camera/Photo class to capture frames and do some image analysis to find areas going lighter and darker.