Unable to move compositor backdrop image using manipulator if outside of view area #54046

New Issue

Antonio Vazquez · 2018-02-10T13:58:19+01:00

Antonio Vazquez commented

2018-02-10 13:58:19 +01:00

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: https://www.dropbox.com/s/7zv4tc0oxtivs7r/UI_Compo_problem.mp4?dl=0

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: https://www.dropbox.com/s/7zv4tc0oxtivs7r/UI_Compo_problem.mp4?dl=0

Antonio Vazquez commented

2018-02-10 13:58:19 +01:00

Added subscriber: @antoniov

Lucas Mota commented

2018-02-19 04:13:44 +01:00

Added subscribers: @ideasman42, @LucasMotaRibeiro-1

Lucas Mota commented

2018-02-19 04:13:44 +01:00

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:
WM_manipulator_types.h:303

        /* 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 @ideasman42 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?

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: `WM_manipulator_types.h:303` ``` /* 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 @ideasman42 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?

Jeroen Bakker commented

2018-03-20 11:27:05 +01:00

Added subscriber: @Jeroen-Bakker

Jeroen Bakker commented

2018-03-20 11:27:05 +01:00

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",
                     ED_MANIPULATOR_CAGE2D_XFORM_FLAG_TRANSLATE | ED_MANIPULATOR_CAGE2D_XFORM_FLAG_SCALE_UNIFORM);
+       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.

``` 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", ED_MANIPULATOR_CAGE2D_XFORM_FLAG_TRANSLATE | ED_MANIPULATOR_CAGE2D_XFORM_FLAG_SCALE_UNIFORM); + 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.

Jeroen Bakker commented

2018-03-20 11:39:06 +01:00

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.

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.

Jeroen Bakker commented

2018-03-20 17:28:46 +01:00

Ok, did some testing on what is possible.

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
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 @ideasman42 what would be a good next step for this.

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 @ideasman42 what would be a good next step for this.

Antonio Vazquez commented

2018-10-24 19:15:15 +02:00

Changed status from 'Open' to: 'Resolved'

Antonio Vazquez closed this issue

2018-10-24 19:15:15 +02:00

Antonio Vazquez self-assigned this 2018-10-24 19:15:15 +02:00

Antonio Vazquez commented

2018-10-24 19:15:15 +02:00

I think this was solved with the new fit button.

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

Unable to move compositor backdrop image using manipulator if outside of view area #54046