Nodes: Socket and title click detection is broken for multiple monitors #104932

New Issue

Limteng · 2023-02-18T22:03:05+01:00

Limteng commented

2023-02-18 22:03:05 +01:00

System Information
Operating system: Windows 11 Home, Version 22H2, OS Build 22621.1265, 64-bit
Graphics card: NVIDIA GeForce RTX 3060 Ti, NVIDIA GeForce RTX 2070 SUPER

Blender Version
Broken: Blender 3.4.1, Blender 3.5.0 Beta (2cd7e70c18), Blender 3.6.0 Alpha (ef60b13c1f)
Worked: (newest version of Blender that worked as expected)

Short description of error

The click detection for node sockets and titles does not work when using main windows in two separate monitors.

This issue is similar to #96255 , but I'm facing this issue even with UI scale = 1.0.

Exact steps for others to reproduce the error

Create a geometry node tree. Node socket/title click detection works properly.
Create a new Main Window. Click detection still works.
Move a main window to another screen. Click detection fails. Clicking and dragging sockets/titles triggers box selection.

(See attached video)

Main monitor: Dell U2720Q
Secondary monitor: LG DualUp 28MQ780

**System Information** Operating system: Windows 11 Home, Version 22H2, OS Build 22621.1265, 64-bit Graphics card: NVIDIA GeForce RTX 3060 Ti, NVIDIA GeForce RTX 2070 SUPER **Blender Version** Broken: Blender 3.4.1, Blender 3.5.0 Beta (2cd7e70c18a8), Blender 3.6.0 Alpha (ef60b13c1f29) Worked: (newest version of Blender that worked as expected) **Short description of error** The click detection for node sockets and titles does not work when using main windows in two separate monitors. This issue is similar to https://projects.blender.org/blender/blender/issues/96255 , but I'm facing this issue even with UI scale = 1.0. **Exact steps for others to reproduce the error** 1. Create a geometry node tree. Node socket/title click detection works properly. 2. Create a new Main Window. Click detection still works. 3. Move a main window to another screen. Click detection fails. Clicking and dragging sockets/titles triggers box selection. (See attached video) Main monitor: Dell U2720Q Secondary monitor: LG DualUp 28MQ780

S4q5bYCrmB-output.mp4

58 MiB

Limteng added the

labels 2023-02-18 22:03:06 +01:00

Limteng referenced this issue

2023-02-18 22:04:42 +01:00

Node socket click detection is broken in some cases #96255

Iliya Katushenock changed title from ~~Geometry node socket and title click detection is broken~~ to Nodes: Socket and title click detection is broken for multiple monitors

2023-02-20 12:19:55 +01:00

Iliya Katushenock commented

2023-02-20 12:21:42 +01:00

Can you tell if it ever worked?

Limteng commented

2023-02-21 07:54:13 +01:00

Can you tell if it ever worked?

@mod_moder The oldest version I tested was 2.93.15, which also had this issue.

> Can you tell if it ever worked? @mod_moder The oldest version I tested was 2.93.15, which also had this issue.

Iliya Katushenock commented

2023-02-21 12:43:40 +01:00

Okay, so let's just hope there are developers out there who are familiar with the specifics of multiple windows or just have multiple monitors to check and confirm that...

Pratik Borhade commented

2023-03-06 12:59:39 +01:00

@Harley hi, can you replicate this on multi-monitor setup?

Harley Acheson commented

2023-03-06 17:45:44 +01:00

@Limteng - Can you you give me a bit of detail about your monitors and how they are arranged?

For example I have three monitors, arranged horizontally, all 1920x1080, and all have their OS scale set to 100%. The middle one is the "main" one.

The arrangement (horizontal, vertical, in a square, etc) can present surprisingly different problems. Knowing which one is the "main" (normally the one with the Task Bar) tells me where the origin point is for your combined desktop. And there can be really interesting complications if the monitors differ in OS scale. I'm not saying any of these things are wrong or will not work, just that I'd like to know your details so that I can recreate what you are seeing exactly.

@Limteng - Can you you give me a bit of detail about your monitors and how they are arranged? For example I have three monitors, arranged horizontally, all 1920x1080, and all have their OS scale set to 100%. The middle one is the "main" one. The arrangement (horizontal, vertical, in a square, etc) can present surprisingly different problems. Knowing which one is the "main" (normally the one with the Task Bar) tells me where the origin point is for your combined desktop. And there can be really interesting complications if the monitors differ in OS scale. I'm not saying any of these things are wrong or will not work, just that I'd like to know your details so that I can recreate what you are seeing exactly.

Harley Acheson self-assigned this 2023-03-06 17:46:00 +01:00

Harley Acheson added

Status

Needs Information from User

and removed

Status

Needs Triage

labels 2023-03-06 17:46:09 +01:00

Harley Acheson commented

2023-03-06 23:09:07 +01:00

I can replicate this behavior IF the monitors differ in OS Scale. One monitor set to 100% while a second is set to 125%.

So far I have only seen this happen on the original window, not on the one that is moved to a different window.

So I have geometry nodes working correctly on any monitor. Then create a new main window (so that it also contains a node editor, and move it to a different monitor that differs in OS scale. Then the first window will have selection issues, but the new window that was moved does not.

I can reverse this. So move my single window to the different monitor, things work. Create a new main window, move it to the first monitor. Again, the one that is not moved starts having selection issues.

The above probably indicates that this is related to the order that these windows are drawn in. We draw at one size, then on the other window at a different size, then back to the first and we use some incorrect calculation.

Note also that while in this state that changing the other window so that it does not use Geometry nodes does not fix it. I'd say it is just the fact they are different scales, not that they are the same editor.

Also note that while in this state of bad selection that other editors in that same window behave correctly. It is just selecting Nodes that fails.

I can replicate this behavior IF the monitors **differ in OS Scale**. One monitor set to 100% while a second is set to 125%. So far I have only seen this happen on the original window, not on the one that is moved to a different window. So I have geometry nodes working correctly on any monitor. Then create a new main window (so that it also contains a node editor, and move it to a different monitor that differs in OS scale. Then the first window will have selection issues, but the new window that was moved does not. I can reverse this. So move my single window to the different monitor, things work. Create a new main window, move it to the first monitor. Again, the one that is not moved starts having selection issues. The above probably indicates that this is related to the order that these windows are drawn in. We draw at one size, then on the other window at a different size, then back to the first and we use some incorrect calculation. Note also that while in this state that changing the other window so that it does not use Geometry nodes does not fix it. I'd say it is just the fact they are different scales, not that they are the same editor. Also note that while in this state of bad selection that other editors in that same window behave correctly. It is just selecting Nodes that fails.

Limteng commented

2023-03-06 23:20:14 +01:00

@Harley Thanks for debugging this. Here is my setup:

Display 1 (main): Dell U2720Q, scale 150%, resolution 3840 x 2160, orientation landscape
Display 2: LG DualUp 28MQ780, scale 125%, resolution 2560 x 2880, orientation portrait

This happened when I moved a Main Window from Display 1 to Display 2.

@Harley Thanks for debugging this. Here is my setup: Display 1 (main): Dell U2720Q, scale 150%, resolution 3840 x 2160, orientation landscape Display 2: LG DualUp 28MQ780, scale 125%, resolution 2560 x 2880, orientation portrait This happened when I moved a Main Window from Display 1 to Display 2.

Screenshot 2023-03-06 141809.png

9.7 KiB

Harley Acheson commented

2023-03-07 02:24:29 +01:00

Haven't gotten too far with this. The usual suspects don't apply...

This isn't our (old) problem where the window is getting the metrics from the last painted window. The value of U.dpi_fac looks to be correct all the time for each window.

The SpaceNode->runtime runtime data looks okay so far. Its cursor values seems correct, and so does aspect. As in these don't change between the working and broken states.

The amount of error is not related to 2D scroll position. It does seem relative to the center of the grid. During this error condition a node that is at grid center will remain selectable, while others have increasing error the further away. The magnitude seems to about the difference in monitor scales at the area edge. For example we are having error on a monitor that is 100% because of another window on a monitor that is 125%. The error at the area outer edges seems about 25% of the distance from the center point. Just a rough guess so far though. But it is definitely not relative to the window or area left. Better stated: In this state (with the "other" monitor at 125%), it thinks the node bounds are all 125% further from the grid center.

Since this condition is always affected by the second window drawn in the windows list, it feels like something that should be in runtime data but is not. But SpaceNode->zoom and SpaceNode->xof are fine.

Might finally see something. When I have one window open and it is working correctly, SpaceNode>edittree->view_center[0] (the x value) is something like 320. I scroll right and it might change to 500, scroll left and it'll go to zero and negative. Makes sense. But if I don't scroll it stays the same.

But..I create a new Main Window. That gets a view_center that is initially the same as the existing one. I scroll this one over and now the two are different. I move my mouse back to the first window (which will now screw up) and I see that I am sometimes getting its correct value, sometimes that of the other window. I close the other window and now I am getting a single value. Probably not the problem itself, but does hint of some values that are shared between these two windows when they should not be.

Haven't gotten too far with this. The usual suspects don't apply... This isn't our (old) problem where the window is getting the metrics from the last painted window. The value of U.dpi_fac looks to be correct all the time for each window. The SpaceNode->runtime runtime data looks okay so far. Its `cursor` values seems correct, and so does `aspect`. As in these don't change between the working and broken states. The amount of error is not related to 2D scroll position. It does seem relative to the center of the grid. During this error condition a node that is at grid center will remain selectable, while others have increasing error the further away. The magnitude seems to about the difference in monitor scales at the area edge. For example we are having error on a monitor that is 100% because of another window on a monitor that is 125%. The error at the area outer edges seems about 25% of the distance from the center point. Just a rough guess so far though. But it is definitely not relative to the window or area left. Better stated: In this state (with the "other" monitor at 125%), it thinks the node bounds are all 125% further from the grid center. Since this condition is always affected by the *second* window drawn in the windows list, it feels like something that should be in runtime data but is not. But SpaceNode->zoom and SpaceNode->xof are fine. Might finally see *something.* When I have one window open and it is working correctly, SpaceNode>edittree->view_center[0] (the x value) is something like 320. I scroll right and it might change to 500, scroll left and it'll go to zero and negative. Makes sense. But if I don't scroll it stays the same. But..I create a new Main Window. That gets a view_center that is initially the same as the existing one. I scroll this one over and now the two are different. I move my mouse back to the first window (which will now screw up) and I see that I am sometimes getting its correct value, sometimes that of the other window. I close the other window and now I am getting a single value. Probably not the problem itself, but does hint of some values that are shared between these two windows when they should not be.

Harley Acheson commented

2023-03-07 20:14:36 +01:00

@HooglyBoogly - I'm not asking you to do anything here, just seeing if you have any quick responses like "known limitation", or "makes sense, look there..."

Explained as simply as I can:

We have a Blender window open on monitor A and it contains a Geometry Node editor. Works great. We "Window / New Main Window" and get a second window that looks the same. We drag that window to Monitor B. We are showing the same node tree in the two windows on different monitors and everything is working fine.

But on the Windows platform we are able to have each monitor have a different scale. So monitor A can be set to "100%" while monitor B can be set to "125%". Doing this generally works just fine. Our Windows are drawn A-B-A-B with a change of U.dpi_fac in between draws.

For these two geometry node editors in these two windows it all looks perfect. The one on monitor B just appears 25% bigger, as expected.

But node selection on monitor A will often not work because it is usually testing against a node->runtime->totr that is sized as if it is on monitor B.

Because of this interference of that runtime value I could think this is a "known limitation" but both editors continue to display just fine; it is only the bounds used for selection that seems to be wrong. And this all works correctly if we have two node editors in the same window with differing aspect.

Does any of this ring a bell?

@HooglyBoogly - I'm not asking you to do anything here, just seeing if you have any quick responses like "known limitation", or "makes sense, look there..." Explained as simply as I can: We have a Blender window open on monitor A and it contains a Geometry Node editor. Works great. We "Window / New Main Window" and get a second window that looks the same. We drag that window to Monitor B. We are showing the same node tree in the two windows on different monitors and everything is working fine. But on the Windows platform we are able to have each monitor have a different scale. So monitor A can be set to "100%" while monitor B can be set to "125%". Doing this generally works just fine. Our Windows are drawn A-B-A-B with a change of U.dpi_fac in between draws. For these two geometry node editors in these two windows it all *looks* perfect. The one on monitor B just appears 25% bigger, as expected. But *node selection* on monitor A will often not work because it is usually testing against a node->runtime->totr that is sized as if it is on monitor B. Because of this interference of that runtime value I could think this is a "known limitation" but both editors continue to display just fine; it is only the bounds used for selection that seems to be wrong. And this all works correctly if we have two node editors in the same window with differing aspect. Does any of this ring a bell?

Iliya Katushenock commented

2023-03-07 20:19:22 +01:00

The mouse should take care of such scaling, I think.

Hans Goudey commented

2023-03-07 20:25:55 +01:00

@Harley Unfortunately it does ring a bell. Recently I had to move the socket locations from the node editor runtime storage to node tree runtime storage. When I did that I realized that totr is stored in region-space. I think it's been like that for ages.

Personally I've always been confused by functions like nodeToView and node_to_view which you may have noticed. The latter converts from the node tree's coordinate space to the node editor's coordinate space, and the former takes care of the fact that nodes are stored relative to their parents (I want to remove that fact in 4.0).

If my theory is right, the proper fix is probably to change bNode::runtime::totr and bNodeTree::runtime::all_socket_locations to be stored in the node tree space without the UI factor applied.

@Harley Unfortunately it does ring a bell. Recently I had to move the socket locations from the node editor runtime storage to node tree runtime storage. When I did that I realized that `totr` is stored in region-space. I think it's been like that for ages. Personally I've always been confused by functions like `nodeToView` and `node_to_view` which you may have noticed. The latter converts from the node tree's coordinate space to the node editor's coordinate space, and the former takes care of the fact that nodes are stored relative to their parents (I want to remove that fact in 4.0). If my theory is right, the proper fix is probably to change `bNode::runtime::totr` and `bNodeTree::runtime::all_socket_locations` to be stored in the node tree space without the UI factor applied.

Harley Acheson commented

2023-03-08 03:05:45 +01:00

@HooglyBoogly - Thanks!

That does make some sense, and I didn't even notice that nodes are relative to their parents. So far not understanding a lot of what's going on in there. So I might be too dumb to help here right now.

@HooglyBoogly - Thanks! That does make some sense, and I didn't even notice that nodes are relative to their parents. So far not understanding a lot of what's going on in there. So I might be too dumb to help here right now.

Iliya Katushenock added

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Nodes: Socket and title click detection is broken for multiple monitors #104932