Commit: 5badaa83903bdb2367aa35701291b38e60ee45b5 Author: Nicholas Rishel Date: Mon May 25 21:26:32 2020 -0700 Branches: master https://developer.blender.org/rB5badaa83903bdb2367aa35701291b38e60ee45b5
Return of the Wintab refactor. Previously Wintab was handled by saving the most recent tablet pressure and tilt information and deferred appending tablet infromation to Windows mouse events. This caused synchronization issues evident at the beginning and ending of strokes where pressure and tilt were either ahead or behind in time from mouse button up or down events. This also dicarded swaths of data which resulted in blockly grease pencil lines most apparent when a context switch resulted in several coalesced mouse events. This patch changes the behavior of Wintab to instead rely entirely on Wintab information for pressure, tilt, position, and button input. Wintab has several design decisions and conventions which complicate relying soley on it's input while retaining current workflows reliant on non-API behavior. For example, many device optionally allow the user to map barrel buttons to non-mouse actions. These mappings may or may not modify the intended behavior when touching the stylus down, such as scroll vs alt mappings. This behavior is not exposed in the Wintab API, but Wintab will continue updating button state sans this necessary context. To work around the problem, this refactor synchronizations tablet input to Windows mouse down and up events, this captures events which should result in pen input while allowing events such as pen scrolling. Until a Windows mouse down event fires Wintab input is left unprocessed; when a Windows up event occurs Wintab is processed until a corresponding button up event is found. Wintab allows for either button state or changes to be reported, but not both. An earlier refactor tried to use button changes to let state to be managed by Wintab. This was replaced when it was found that button change events were unreliable at corner cases such as switching windows. It was also found that with Wacom drivers Wintab peek functions would modify events in the queue causing errant and loss of button events. For the latter stated reason this patch opts to read all Wintab events into a queue as they arrive, removing events as they become stale. This was chosen over using Wintab peek functions due to the afformentioned issue. As a bonus this seems to work better as it prevents the queue in Wintab from filling, thus neither a flood of events need to be handled when Wintab processing begins and a Wintab implementation need not be trusted to overwrite old events in it's queue. Maniphest Tasks: T75566 Differential Revision: https://developer.blender.org/D7840 =================================================================== M intern/ghost/intern/GHOST_SystemWin32.cpp =================================================================== diff --git a/intern/ghost/intern/GHOST_SystemWin32.cpp b/intern/ghost/intern/GHOST_SystemWin32.cpp index 7a52933b258..ca2c6c576fa 100644 --- a/intern/ghost/intern/GHOST_SystemWin32.cpp +++ b/intern/ghost/intern/GHOST_SystemWin32.cpp @@ -1049,6 +1049,16 @@ GHOST_TSuccess GHOST_SystemWin32::processWintabEvents(GHOST_TEventType type, // associated button event. Because Wintab and their associated Windows mouse events are handled // asynchronously, and there's no way to turn off if (unhandledButton) { + if (!window->wintabSysButPressed()) { + GHOST_TInt32 x, y; + system->getCursorPosition(x, y); + system->pushEvent(new GHOST_EventCursor(system->getMilliSeconds(), + GHOST_kEventCursorMove, + window, + x, + y, + GHOST_TABLET_DATA_NONE)); + } system->pushEvent(new GHOST_EventButton( system->getMilliSeconds(), type, window, mask, GHOST_TABLET_DATA_NONE)); } _______________________________________________ Bf-blender-cvs mailing list Bf-blender-cvs@blender.org https://lists.blender.org/mailman/listinfo/bf-blender-cvs
