Page MenuHome

Unable to move compositor backdrop image using manipulator if outside of view area
Closed, ResolvedPublic


Blender 2.8
Windows 64 bits

If you use the backdrop image and move the display image using the manipulator outside the view area, you cannot move again the image because the scroll bars don't move the image.

See this video:



Event Timeline

Campbell Barton (campbellbarton) triaged this task as Confirmed, Medium priority.Feb 19 2018, 1:10 AM

Confirmed on Blender 2.8 - Arch Linux x64.

It's also possible to see that there is no strong association between using the manipulators or the backdrop's toolbar on the right.
More specifically, when you drag the backdrop, there is no change in the offset until you hover the sidebar also when you use the Move button and the handlers don't move with it (only when you deselect and select the view node).

Reading more of the code I've seen this piece that could cause part of the problem above:

        /* Returns the final transformation which may be different from the 'matrix',
	 * depending on the manipulator.
	 * Notes:
	 * - Scale isn't applied (wmManipulator.scale/user_scale).
	 * - Offset isn't applied (wmManipulator.matrix_offset).
	wmManipulatorFnMatrixBasisGet matrix_basis_get;

Watching the code, I've seen that @Campbell Barton (campbellbarton) wrote part of the manipulators. Maybe he could give some insights.

Also, what would be the best approach to avoid missing the manipulators on the scene ? Or should we just guarantee the consistency of the toolbar and manipulators information?

diff --git a/source/blender/editors/space_node/node_manipulators.c b/source/blender/editors/space_node/node_manipulators.c
index 73b0f44b043..a62c0065594 100644
--- a/source/blender/editors/space_node/node_manipulators.c
+++ b/source/blender/editors/space_node/node_manipulators.c
@@ -134,6 +134,7 @@ static void WIDGETGROUP_node_transform_setup(const bContext *UNUSED(C), wmManipu
        RNA_enum_set(wwrapper->manipulator->ptr, "transform",
+       RNA_enum_set(wwrapper->manipulator->ptr, "draw_options", 0);
        mgroup->customdata = wwrapper;

Would fix this issues, but as manipulators are implemented as modal operations, it is not possible to select a node that is on top of the backdrop which is also annoying. There should be some mechanism that these manipulators are not 'fully' modal.

Currently only the selection of the node will work if no handler of the manipulator will not get any focus.

We should have a mechanism that gets all valid events and have an ordering to select the event that will be handled.
In the manipulator we could add a flag that other events will get precedence over the manipulator events.
And add that flag to the backdrop manipulator.
Another solution is a priority of the event to use as ordering.

Ok, did some testing on what is possible.

  1. When implementing the fallback code in the event handler (or changing the order of the event handler list of the space_node this was possible, but came to another issue. Mouse cursor was not displayed correctly as manipulators are modal operators
  2. the solution might be that we make the wm_manipulatormap_highlight_find context aware and not finding manipulator handlers that are obstructed by for example a nodes in the space_node when the manipulator has the fallback-flag set.

Will check with @Campbell Barton (campbellbarton) what would be a good next step for this.

Antonio Vazquez (antoniov) claimed this task.

I think this was solved with the new fit button.