Core: Explicitly throttle mousemove events #110148
Closed
Joseph Eagar
wants to merge 1 commits from
When changing the target branch, be careful to rebase the branch in your fork to match. See documentation.
JosephEagar/blender:fix-inbetween-mousemove
into main
pull from: JosephEagar/blender:fix-inbetween-mousemove
merge into: blender:main
blender:main
blender:universal-scene-description
blender:brush-assets-project
blender:blender-v3.3-release
blender:blender-v3.6-release
blender:partial-write-refactor
blender:blender-v4.1-release
blender:blender-v3.6-temp_wmoss_animrig_public
blender:temp-sculpt-dyntopo
blender:gpencil-next
blender:anim/animation-id-113594
blender:blender-v4.0-release
blender:blender-projects-basics
blender:bridge-curves
blender:sculpt-blender
blender:asset-browser-frontend-split
blender:asset-shelf
blender:tmp-usd-python-mtl
blender:tmp-usd-3.6
blender:blender-v3.5-release
blender:blender-v2.93-release
blender:realtime-clock
blender:sculpt-dev
blender:bevelv2
blender:xr-dev
When changing the target branch, be careful to rebase the branch in your fork to match. See documentation.
1 Commits
Author | SHA1 | Message | Date |
---|---|---|---|
Joseph Eagar | 4a6de9c13e |
Core: Explicitly throttle mousemove events
The behavior of INBETWEEN_MOUSEMOVE was indeterminate. Apparently the idea was to drop mousemove events for some tools during heavy CPU load; this was implemented by changing the type of runs of MOUSEMOVE events inside the event queue to INBETWEEN_MOUSEMOVE, with only the event at the head of the queue MOUSEMOVE. Basically the size of the event queue was used to throttle MOUSEMOVE events, presumably under the assumption that the size of the queue is proportional to CPU and GPU load. This turned out to be incorrect. This PR removes the old behavior and uses a simple time limit instead for throttling. There is a maximum number of MOUSEMOVE events per second (MOUSEMOVES_PER_SECOND) and events that fail this limit are retyped to INBETWEEN_MOUSEMOVE. |