event.mouse_x and event.mouse_prev_x don't give consistent results across all tablets/mouse API as they used to in blender 2.91 #84912

New Issue

Adrian Rutkowski · 2021-01-20T21:33:08+01:00

Adrian Rutkowski commented

2021-01-20 21:33:08 +01:00

System Information
Operating system: win10

Blender Version
Broken: (example: 2.92.0-c2e6969c56ef-windows64 and 2.93.0-6290091bace2-windows64 )
Worked: (2.91.2)

Short description of error

changing tablet API no longer gives consistent results for python scripts when event.mouse_x and event.mouse_prev_x are used

AZzNtnWtai.mp4

here is the script I used in a video

import bpy
from bpy.props import IntProperty, FloatProperty


class ModalOperator(bpy.types.Operator):
    """Move an object with the mouse, example"""
    bl_idname = "object.modal_operator"
    bl_label = "Simple Modal Operator"

    first_value: FloatProperty()

    def modal(self, context, event):
        if event.type == 'MOUSEMOVE':
            context.object.location.x += (event.mouse_x - event.mouse_prev_x) / 10

        elif event.type == 'LEFTMOUSE':
            return {'FINISHED'}

        elif event.type in {'RIGHTMOUSE', 'ESC'}:
            context.object.location.x = self.first_value
            return {'CANCELLED'}

        return {'RUNNING_MODAL'}

    def invoke(self, context, event):
        if context.object:
            self.first_value = context.object.location.x

            context.window_manager.modal_handler_add(self)
            return {'RUNNING_MODAL'}
        else:
            self.report({'WARNING'}, "No active object, could not finish")
            return {'CANCELLED'}


def register():
    bpy.utils.register_class(ModalOperator)


def unregister():
    bpy.utils.unregister_class(ModalOperator)


if __name__ == "__main__":
    register()

    # test call
    bpy.ops.object.modal_operator('INVOKE_DEFAULT')

**System Information** Operating system: win10 **Blender Version** Broken: (example: 2.92.0-c2e6969c56ef-windows64 and 2.93.0-6290091bace2-windows64 ) Worked: (2.91.2) **Short description of error** changing tablet API no longer gives consistent results for python scripts when event.mouse_x and event.mouse_prev_x are used [AZzNtnWtai.mp4](https://archive.blender.org/developer/F9590022/AZzNtnWtai.mp4) here is the script I used in a video ``` import bpy from bpy.props import IntProperty, FloatProperty class ModalOperator(bpy.types.Operator): """Move an object with the mouse, example""" bl_idname = "object.modal_operator" bl_label = "Simple Modal Operator" first_value: FloatProperty() def modal(self, context, event): if event.type == 'MOUSEMOVE': context.object.location.x += (event.mouse_x - event.mouse_prev_x) / 10 elif event.type == 'LEFTMOUSE': return {'FINISHED'} elif event.type in {'RIGHTMOUSE', 'ESC'}: context.object.location.x = self.first_value return {'CANCELLED'} return {'RUNNING_MODAL'} def invoke(self, context, event): if context.object: self.first_value = context.object.location.x context.window_manager.modal_handler_add(self) return {'RUNNING_MODAL'} else: self.report({'WARNING'}, "No active object, could not finish") return {'CANCELLED'} def register(): bpy.utils.register_class(ModalOperator) def unregister(): bpy.utils.unregister_class(ModalOperator) if __name__ == "__main__": register() # test call bpy.ops.object.modal_operator('INVOKE_DEFAULT') ```

Adrian Rutkowski commented

2021-01-20 21:33:08 +01:00

Added subscriber: @niewinny

Nicholas Rishel commented

2021-01-20 22:38:17 +01:00

Added subscriber: @PrototypeNM1

Nicholas Rishel commented

2021-01-20 22:38:17 +01:00

This is probably a result of tablets and mice now receiving high frequency input on Windows.

Someone else would need to comment on how that would impact mouse_* and mouse_prev_* and whether this is a bug in the script or a bug in how events are generated. I'd be concerned with how cursor input coalescing interacts with what is reported as the previous cursor position.

This is probably a result of tablets and mice now receiving high frequency input on Windows. Someone else would need to comment on how that would impact mouse_* and mouse_prev_* and whether this is a bug in the script or a bug in how events are generated. I'd be concerned with how cursor input coalescing interacts with what is reported as the previous cursor position.

Adrian Rutkowski commented

2021-01-21 12:15:36 +01:00

Just to make it clearer, I included the script so it's easier to test, but in general (mouse_* - mouse_prev_*) is giving different results for wintab and windows ink APIs.

since there were some changes to input and the mouse is giving the same input as Wintab I assume windows ink was not updated.
unless it is not possible to do it for windows ink API

Just to make it clearer, I included the script so it's easier to test, but in general (mouse_* - mouse_prev_*) is giving different results for wintab and windows ink APIs. since there were some changes to input and the mouse is giving the same input as Wintab I assume windows ink was not updated. unless it is not possible to do it for windows ink API

Nicholas Rishel commented

2021-01-25 05:28:56 +01:00

I'm just adding context for whoever ends up addressing this issue. Windows Ink and Wintab both feed into the same system (from Ghost to the Window Manager), and what they feed into that system doesn't include the idea of a mouse_prev_*. Thus the issue is likely exposed by recent changes to Windows Ink and Wintab, but unlikely to be contained in the changes to Windows Ink and Wintab.

I suspect the issue is the Window Manager and how it coalesces mouse input, and how that interacts with saving mouse_prev_. I don't think mouse_prev_ is updated taking into account whether the operator is receiving all mouse input or just the most recent mouse input. Assuming that is the case it would result in different behavior when many more mouse events are generated and when they're fed to the Window Manager in different "clumps" (e.g. 2 at a time vs. 7 at a time), which is a probable source of the bug given Windows Ink, Wintab, and Windows mouse events are read in different ways.

I'm just adding context for whoever ends up addressing this issue. Windows Ink and Wintab both feed into the same system (from Ghost to the Window Manager), and what they feed into that system doesn't include the idea of a mouse_prev_*. Thus the issue is likely exposed by recent changes to Windows Ink and Wintab, but unlikely to be contained in the changes to Windows Ink and Wintab. I suspect the issue is the Window Manager and how it coalesces mouse input, and how that interacts with saving mouse_prev_*. I don't think mouse_prev_* is updated taking into account whether the operator is receiving all mouse input or just the most recent mouse input. Assuming that is the case it would result in different behavior when many more mouse events are generated and when they're fed to the Window Manager in different "clumps" (e.g. 2 at a time vs. 7 at a time), which is a probable source of the bug given Windows Ink, Wintab, and Windows mouse events are read in different ways.

Campbell Barton commented

2021-01-27 07:31:42 +01:00

Added subscriber: @ideasman42

Campbell Barton commented

2021-01-27 07:31:42 +01:00

Does this also happen when checking INBETWEEN_MOUSEMOVE events too?

Removing Python project, since this isn't spesific to Python (it will impact C code too).

Does this also happen when checking `INBETWEEN_MOUSEMOVE` events too? Removing Python project, since this isn't spesific to Python (it will impact C code too).

Nicholas Rishel commented

2021-01-30 20:29:19 +01:00

Changed status from 'Needs Triage' to: 'Needs User Info'

Philipp Oeser commented

2021-03-24 15:46:59 +01:00

Added subscriber: @lichtwerk

Philipp Oeser commented

2021-03-24 15:46:59 +01:00

Changed status from 'Needs User Info' to: 'Archived'

Philipp Oeser closed this issue

2021-03-24 15:46:59 +01:00

Philipp Oeser commented

2021-03-24 15:46:59 +01:00

No activity for more than a week. As per the tracker policy we assume the issue is gone and can be closed.

Thanks again for the report. If the problem persists please open a new report with the required information.

No activity for more than a week. As per the tracker policy we assume the issue is gone and can be closed. Thanks again for the report. If the problem persists please open a new report with the required information.

Sign in to join this conversation.

No Label

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

event.mouse_x and event.mouse_prev_x don't give consistent results across all tablets/mouse API as they used to in blender 2.91 #84912