Fix #106043: Moving frame node jittering while cursor is still #106096

Merged
Philipp Oeser merged 1 commits from lichtwerk/blender:106043 into main 2023-03-30 14:02:56 +02:00
Member

The fix for #105363 (6d3ce8273a) made the transform system respect
(Frame) nodes offsetx/offsety.

Now Node Editors run the transform system even if the mouse is still (due to edge panning -- unnecessarily, see PR #106301 for fixing this). And due to the way frame_node_prepare_for_draw recalculates these offsets (based on
on updated positions and node.runtime->totr [which in turn gets rounded in node_update_basis -- so subpixel precision is lost there, see [1]]), this can lead to slight imprecisions/noise/jitter during transform (if we use float offsets, see the PR for more info).

So to counter this, use rounded offsets now [which will keep the whole circle stable].

NOTE: PR #106301 would fix this already for having the cursor still, but this patch still improves slight jitter when moving, so will commit separately.

[1] comment from node_update_basis

/* Round the node origin because text contents are always pixel-aligned. */

The fix for #105363 (6d3ce8273a) made the transform system respect (Frame) nodes `offsetx`/`offsety`. Now Node Editors run the transform system even if the mouse is still (due to edge panning -- unnecessarily, see PR #106301 for fixing this). And due to the way `frame_node_prepare_for_draw` recalculates these offsets (based on on updated positions and `node.runtime->totr` [which in turn gets rounded in `node_update_basis` -- so subpixel precision is lost there, see [1]]), this can lead to slight imprecisions/noise/jitter during transform (if we use float offsets, see the PR for more info). So to counter this, use rounded offsets now [which will keep the whole circle stable]. NOTE: PR #106301 would fix this already for having the cursor still, but this patch still improves slight jitter when moving, so will commit separately. [1] comment from `node_update_basis` > /* Round the node origin because text contents are always pixel-aligned. */
Philipp Oeser added this to the Nodes & Physics project 2023-03-24 11:38:27 +01:00
Philipp Oeser added the
Interest
Modeling
label 2023-03-24 11:38:42 +01:00
Philipp Oeser requested review from Germano Cavalcante 2023-03-24 11:38:57 +01:00
Philipp Oeser requested review from Hans Goudey 2023-03-24 11:39:06 +01:00
Author
Member

CC @SimonThommes (maybe you could check if this is working as intended for you)

CC @SimonThommes (maybe you could check if this is working as intended for you)
Simon Thommes approved these changes 2023-03-24 11:54:41 +01:00
Simon Thommes left a comment
Member

Yup, behavior seems good to me 👍

Yup, behavior seems good to me 👍

I'm still confused how this fixes the problem.

I suggest putting a comment in the code explaining the reasons for using offset and round.

Overall it looks OK

I'm still confused how this fixes the problem. I suggest putting a comment in the code explaining the reasons for using offset and round. Overall it looks OK
Germano Cavalcante approved these changes 2023-03-24 13:43:19 +01:00

I still don’t fully understand why you need to take into account local offset if there are no parents

I still don’t fully understand why you need to take into account local offset if there are no parents
Author
Member

I still don’t fully understand why you need to take into account local offset if there are no parents

Frame nodes themselves have offsets (even if they dont have parents), they get that in frame_node_prepare_for_draw (from the bounding box of they children) if I am not mistaken.

> I still don’t fully understand why you need to take into account local offset if there are no parents Frame nodes themselves have offsets (even if they dont have parents), they get that in `frame_node_prepare_for_draw` (from the bounding box of they children) if I am not mistaken.

Yes, I just forgot some specifics...
Indeed, it would be nice, if a future we could have a cache of parametric node data and delegate the movement of children by the parent from operator, but not from updates.

Yes, I just forgot some specifics... Indeed, it would be nice, if a future we could have a cache of parametric node data and delegate the movement of children by the parent from operator, but not from updates.
Hans Goudey changed title from Fix #106043 : Moving frame node jittering while cursor is still to Fix #106043: Moving frame node jittering while cursor is still 2023-03-29 19:37:05 +02:00
Author
Member

Taking a step back, I am now a bit puzzled we even get MOUSEMOVE events for the transform system in the Node Editors (when the mouse is not moving). This does not seem to be the case with the transform system in other editors (except the VSE).

Th fix is still legit, but will investigate a bit more why the above is the case...

Taking a step back, I am now a bit puzzled we even get `MOUSEMOVE` events for the transform system in the Node Editors (when the mouse is not moving). This does not seem to be the case with the transform system in other editors (except the VSE). Th fix is still legit, but will investigate a bit more why the above is the case...
Author
Member

Taking a step back, I am now a bit puzzled we even get MOUSEMOVE events for the transform system in the Node Editors (when the mouse is not moving). This does not seem to be the case with the transform system in other editors (except the VSE).

Th fix is still legit, but will investigate a bit more why the above is the case...

Ah, this is caused by edge panning which does a WM_event_add_mousemove (next to other unnecessary updates) even if it is not panning at all. Will post another PR to rectify this in a bit.

> Taking a step back, I am now a bit puzzled we even get `MOUSEMOVE` events for the transform system in the Node Editors (when the mouse is not moving). This does not seem to be the case with the transform system in other editors (except the VSE). > > Th fix is still legit, but will investigate a bit more why the above is the case... Ah, this is caused by edge panning which does a `WM_event_add_mousemove` (next to other unnecessary updates) even if it is not panning at all. Will post another PR to rectify this in a bit.
Author
Member

Ah, this is caused by edge panning which does a WM_event_add_mousemove (next to other unnecessary updates) even if it is not panning at all. Will post another PR to rectify this in a bit.

PR for this is #106301

> Ah, this is caused by edge panning which does a `WM_event_add_mousemove` (next to other unnecessary updates) even if it is not panning at all. Will post another PR to rectify this in a bit. PR for this is #106301
Author
Member

So as for why we need to do the rounding:

  • node.runtime->totr [which frame_node_prepare_for_draw to recalculate the offset] is rounded in node_update_basis, see this comment:

/* Round the node origin because text contents are always pixel-aligned. */

  • this might get rounded down, then when we include (float) offset into the mix, it might get rounded up, then adding the (float) offset again, it might get rounded down again... ending in the jittering. Commenting the rounding in node_update_basis would make the frame nodes (and their children) perfectly stable -- but result in the texts floating/wobbeling.

I will update the commit message to make this more clear.

So as for why we need to do the rounding: - `node.runtime->totr` [which `frame_node_prepare_for_draw` to recalculate the offset] is rounded in `node_update_basis`, see this comment: > /* Round the node origin because text contents are always pixel-aligned. */ - this might get rounded down, then when we include (float) offset into the mix, it might get rounded up, then adding the (float) offset again, it might get rounded down again... ending in the jittering. Commenting the rounding in `node_update_basis` would make the frame nodes (and their children) perfectly stable -- but result in the texts floating/wobbeling. I will update the commit message to make this more clear.
lichtwerk changed target branch from blender-v3.5-release to main 2023-03-30 13:46:48 +02:00
Philipp Oeser force-pushed 106043 from 7c4f539252 to cefe001793 2023-03-30 13:48:24 +02:00 Compare
Philipp Oeser merged commit 2a6f177e8e into main 2023-03-30 14:02:56 +02:00
Sign in to join this conversation.
No Label
Interest
Alembic
Interest
Animation & Rigging
Interest
Asset Browser
Interest
Asset Browser Project Overview
Interest
Audio
Interest
Automated Testing
Interest
Blender Asset Bundle
Interest
BlendFile
Interest
Collada
Interest
Compatibility
Interest
Compositing
Interest
Core
Interest
Cycles
Interest
Dependency Graph
Interest
Development Management
Interest
EEVEE
Interest
EEVEE & Viewport
Interest
Freestyle
Interest
Geometry Nodes
Interest
Grease Pencil
Interest
ID Management
Interest
Images & Movies
Interest
Import Export
Interest
Line Art
Interest
Masking
Interest
Metal
Interest
Modeling
Interest
Modifiers
Interest
Motion Tracking
Interest
Nodes & Physics
Interest
OpenGL
Interest
Overlay
Interest
Overrides
Interest
Performance
Interest
Physics
Interest
Pipeline, Assets & IO
Interest
Platforms, Builds & Tests
Interest
Python API
Interest
Render & Cycles
Interest
Render Pipeline
Interest
Sculpt, Paint & Texture
Interest
Text Editor
Interest
Translations
Interest
Triaging
Interest
Undo
Interest
USD
Interest
User Interface
Interest
UV Editing
Interest
VFX & Video
Interest
Video Sequencer
Interest
Virtual Reality
Interest
Vulkan
Interest
Wayland
Interest
Workbench
Interest: X11
Legacy
Blender 2.8 Project
Legacy
Milestone 1: Basic, Local Asset Browser
Legacy
OpenGL Error
Meta
Good First Issue
Meta
Papercut
Meta
Retrospective
Meta
Security
Module
Animation & Rigging
Module
Core
Module
Development Management
Module
EEVEE & Viewport
Module
Grease Pencil
Module
Modeling
Module
Nodes & Physics
Module
Pipeline, Assets & IO
Module
Platforms, Builds & Tests
Module
Python API
Module
Render & Cycles
Module
Sculpt, Paint & Texture
Module
Triaging
Module
User Interface
Module
VFX & Video
Platform
FreeBSD
Platform
Linux
Platform
macOS
Platform
Windows
Priority
High
Priority
Low
Priority
Normal
Priority
Unbreak Now!
Status
Archived
Status
Confirmed
Status
Duplicate
Status
Needs Info from Developers
Status
Needs Information from User
Status
Needs Triage
Status
Resolved
Type
Bug
Type
Design
Type
Known Issue
Type
Patch
Type
Report
Type
To Do
No Milestone
No Assignees
4 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: blender/blender#106096
No description provided.