Incorrect UI state after joining a narrow editor #100772

New Issue

Konstantins Visnevskis · 2022-09-02T13:30:44+02:00

2022-09-02 13:30:44 +02:00

System Information
Operating system: Windows-10-10.0.19043-SP0 64 Bits
Graphics card: NVIDIA GeForce RTX 2080 Ti/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 512.15

Blender Version
Broken: version: 3.2.2, branch: master, commit date: 2022-08-02 18:15, hash: bcfdb14560

Short description of error
After joining regions, the separating line remains on the screen and has a limiting effect on resizing regions under.

Exact steps for others to reproduce the error

Join the leftmost top region with the leftmost bottom. A region intersection triangle appears between regions.
Now if you join across them, a region separation line can be seen halfway across vewport.
regions.blend

**System Information** Operating system: Windows-10-10.0.19043-SP0 64 Bits Graphics card: NVIDIA GeForce RTX 2080 Ti/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 512.15 **Blender Version** Broken: version: 3.2.2, branch: master, commit date: 2022-08-02 18:15, hash: `bcfdb14560` **Short description of error** After joining regions, the separating line remains on the screen and has a limiting effect on resizing regions under. **Exact steps for others to reproduce the error** - Join the leftmost top region with the leftmost bottom. A region intersection triangle appears between regions. - Now if you join across them, a region separation line can be seen halfway across vewport. [regions.blend](https://archive.blender.org/developer/F13451553/regions.blend) ![region.jpg](https://archive.blender.org/developer/F13451555/region.jpg)

Konstantins Visnevskis commented

2022-09-02 13:30:44 +02:00

Added subscriber: @KonstantinsVisnevskis

Omar Emara commented

2022-09-02 13:47:54 +02:00

Added subscriber: @OmarEmaraDev

Omar Emara commented

2022-09-02 13:47:54 +02:00

Changed status from 'Needs Triage' to: 'Confirmed'

Omar Emara commented

2022-09-02 13:47:54 +02:00

I can't reproduce the issue from scratch, but I can reproduce it on the provided file. It seems to be caused by the very small Text editor in the layout.
Resizing editors also doesn't work correctly after joining as demonstrated in the following video.

20220902-134518.mp4

I can't reproduce the issue from scratch, but I can reproduce it on the provided file. It seems to be caused by the very small Text editor in the layout. Resizing editors also doesn't work correctly after joining as demonstrated in the following video. [20220902-134518.mp4](https://archive.blender.org/developer/F13451579/20220902-134518.mp4)

Omar Emara changed title from ~~An artifact of joining narrow region~~ to Incorrect UI state after joining a narrow editor

2022-09-02 13:48:59 +02:00

Pratik Borhade commented

2022-09-02 14:07:13 +02:00

Added subscribers: @Harley, @lichtwerk, @PratikPB2123

Pratik Borhade commented

2022-09-02 14:07:14 +02:00

It seems to be caused by the very small Text editor in the layout.

This note helped me to repro the issue from scratch.
We had received similar report before but got closed due to not having the exact way to reproduce from scratch: #89686 (Half line stuck after combining multiple split screens)
cc @Harley @lichtwerk

> It seems to be caused by the very small Text editor in the layout. This note helped me to repro the issue from scratch. We had received similar report before but got closed due to not having the exact way to reproduce from scratch: #89686 (Half line stuck after combining multiple split screens) cc @Harley @lichtwerk

Harley Acheson self-assigned this 2022-09-02 17:38:10 +02:00

Harley Acheson commented

2022-09-02 17:38:10 +02:00

Thanks!!!

This is caused in this file because the width of the area (highlighted with arrows) is narrower than we allow. Under normal operation we don't allow users to make or resize an area that is narrower than AREAMINX (32 pixels at 1X scale) or shorter than HEADERY (26 pixels at 1X scale).

You can see this if you try resizing that area in that it will "snap" to a wider width. After that you can join A to B or B to A without issue.

I see now that I can make an area that narrow by first resizing the entire window over two monitors, resize an area to minimum, then size the window back down to one window. Our area scaling does it all proportional so this results in an area that is too narrow. I'm not aware of other ways of creating such a narrow area, and would appreciate being told of other ways of doing so.

I'll have to see what I can do in this situation. I can't really leave a narrow strip like that, and don't want to delete the little area. I might have to disallow the join. Will give it some thought.

{F13452148,width=100%}

Thanks!!! This is caused in this file because the width of the area (highlighted with arrows) is narrower than we allow. Under normal operation we don't allow users to make or resize an area that is narrower than AREAMINX (32 pixels at 1X scale) or shorter than HEADERY (26 pixels at 1X scale). You can see this if you try resizing that area in that it will "snap" to a wider width. After that you can join A to B or B to A without issue. I see now that I can make an area that narrow by first resizing the entire window over two monitors, resize an area to minimum, then size the window back down to one window. Our area scaling does it all proportional so this results in an area that is too narrow. I'm not aware of other ways of creating such a narrow area, and would appreciate being told of other ways of doing so. I'll have to see what I can do in this situation. I can't really leave a narrow strip like that, and don't want to delete the little area. I might have to disallow the join. Will give it some thought. {[F13452148](https://archive.blender.org/developer/F13452148/image.png),width=100%}

Konstantins Visnevskis commented

2022-09-02 21:17:33 +02:00

Yeah, deleting small editors automatically would change UI resizing feel considerably (and would be weird if it'd happen only on window resize). Would a minimum size check-and-fix on window resize have any downsides?
Edit: In my case the window usually is either maximized or smaller than monitor, but I do usually work with more than one, which might be how this happened. On the other hand, it seemed that I can resize the area larger and then back to what can be seen, getting the same result (will check at a chance). I'm blabbing, but could that also have anything to do with Windows 2x scaling for hi-res monitors? ...perhaps something with rounding-up the 2x pixel size to "real" dimension?

Yeah, deleting small editors automatically would change UI resizing feel considerably (and would be weird if it'd happen only on window resize). Would a minimum size check-and-fix on window resize have any downsides? Edit: In my case the window usually is either maximized or smaller than monitor, but I do usually work with more than one, which might be how this happened. On the other hand, it seemed that I can resize the area larger and then back to what can be seen, getting the same result (will check at a chance). I'm blabbing, but could that also have anything to do with Windows 2x scaling for hi-res monitors? ...perhaps something with rounding-up the 2x pixel size to "real" dimension?

Harley Acheson commented

2022-09-02 22:03:08 +02:00

Yes, I'm looking at all this now, but might take a bit to find a nice solution. Constraining on resize might be part of it. We do have times where the minimums are not checked and others where the minimums aren't scaled correctly.

Harley Acheson commented

2022-09-03 00:26:26 +02:00

It turns out that it is much more likely to get a bad result when your UI resolution is greater than 1. This is because we are often not scaling our minimum area values by resolution. I correct this is the following patch: D15865: UI: Corrected Scaling of AREAMINX

But I don't want to represent that as a complete fix without also addressing the other vector: scaling an entire window down can create areas that are smaller than the minimums. Will hopefully look at that fairly soon.

It turns out that it is much more likely to get a bad result when your UI resolution is greater than 1. This is because we are often not scaling our minimum area values by resolution. I correct this is the following patch: [D15865: UI: Corrected Scaling of AREAMINX ](https://archive.blender.org/developer/D15865) But I don't want to represent that as a *complete* fix without also addressing the other vector: scaling an entire window down can create areas that are smaller than the minimums. Will hopefully look at that fairly soon.

Ludvik Koutny commented

2022-09-03 09:28:19 +02:00

Added subscriber: @Rawalanche

Ludvik Koutny commented

2022-09-03 09:28:20 +02:00

Deleting the small areas doesn't sound like acceptable solution, and neither does disallowing the join, because that would be jarring to the user. In fact, when someone sees such a small area, common instinct may be that it was created in an error, so they will probably want to close it by joining. So it would be very odd when the users would have to be aware of this corner case to know that joining not working is not a bug in this very specific scenario.

What sounds the most reasonable to me is simply check and fix, as described above. There should just be no condition under which area below min size can be created, and additional check to correct ones that were somehow created back to the proper min size.

Deleting the small areas doesn't sound like acceptable solution, and neither does disallowing the join, because that would be jarring to the user. In fact, when someone sees such a small area, common instinct may be that it was created in an error, so they will probably want to close it by joining. So it would be very odd when the users would have to be aware of this corner case to know that joining not working is not a bug in this very specific scenario. What sounds the most reasonable to me is simply check and fix, as described above. There should just be no condition under which area below min size can be created, and additional check to correct ones that were somehow created back to the proper min size.

Harley Acheson commented

2022-09-03 15:58:51 +02:00

@Rawalanche - There should just be no condition under which area below min size can be created, and additional check to correct ones that were somehow created back to the proper min size.

Yes, that is exactly what I am doing, as mentioned in my previous comments. I have one patch (linked above) that corrects for the times we do not properly scale that minimum value - which seems common on high-dpi displays. I'll be submitting another that ensures that areas do not drop below minimum while scaling the window. Fairly certain these are the only two methods of creating such a small area.

> @Rawalanche - There should just be no condition under which area below min size can be created, and additional check to correct ones that were somehow created back to the proper min size. Yes, that is exactly what I am doing, as mentioned in my previous comments. I have one patch (linked above) that corrects for the times we do not properly scale that minimum value - which seems common on high-dpi displays. I'll be submitting another that ensures that areas do not drop below minimum while scaling the window. Fairly certain these are the only two methods of creating such a small area.

blender-admin commented

2022-09-05 19:37:15 +02:00

This issue was referenced by d26a0be968

This issue was referenced by d26a0be968e09a89bc0cd49dd08aba3e08a28aad

Campbell Barton commented

2022-09-23 02:35:52 +02:00

Added subscriber: @ideasman42

Campbell Barton commented

2022-09-23 02:35:52 +02:00

As windows can be resized & the DPI can change at run-time, preventing this situation can't be avoided entirely.

It should be possible to detect a join that would create a corrupt layout and disallow it (in this case - behave as if the narrow area is at least AREAMINX) wide.

As windows can be resized & the DPI can change at run-time, preventing this situation can't be avoided entirely. It should be possible to detect a join that would create a corrupt layout and disallow it (in this case - behave as if the narrow area is at least `AREAMINX`) wide.

Harley Acheson commented

2022-09-23 03:51:33 +02:00

Its a little complicated but I think I can check for this potential issue by looking at the sizes of areas that have any portion within the union of the source and destination areas. If there is anything encroaching that is below the minimum size I can just disallow. That leaves the possibility of later somehow preventing windows from getting sub-minimum size and therefore never get disallowed.

I don't think I can do this within 3.4, but for 3.5 seems reasonable. I think we've had 2-4 related complaints since complex joins were added in 3.0 and fairly certain the majority would be fixed by D15865: UI: Corrected Scaling of AREAMINX

Its a little complicated but I *think* I can check for this potential issue by looking at the sizes of areas that have any portion within the **union** of the source and destination areas. If there is anything encroaching that is below the minimum size I can just disallow. That leaves the possibility of later somehow preventing windows from getting sub-minimum size and therefore never get disallowed. I don't *think* I can do this within 3.4, but for 3.5 seems reasonable. I think we've had 2-4 related complaints since complex joins were added in 3.0 and fairly certain the majority would be fixed by [D15865: UI: Corrected Scaling of AREAMINX ](https://archive.blender.org/developer/D15865)

blender-admin commented

2022-11-16 18:06:03 +01:00

This issue was referenced by a81abbbb8f

This issue was referenced by a81abbbb8f047f969cbe26ceeb6223d623f4e234

Harley Acheson commented

2022-11-16 18:09:10 +01:00

Changed status from 'Confirmed' to: 'Resolved'

Harley Acheson closed this issue

2022-11-16 18:09:10 +01:00

Pratik Borhade referenced this issue

2024-03-21 07:03:15 +01:00

Weird UI thing in the Viewport view #119666