UI breaks after moving the Blender window between monitors of different resolutions #100618

New Issue

Artur · 2022-08-24T19:52:41+02:00

Artur commented

2022-08-24 19:52:41 +02:00

System Information
Operating system: Windows 10
Graphics card: Nvidia GTX 1060

Blender Version
Broken: Blender 3.2.2

Short description of error
I have two monitors with different resolutions. When I drag the Blender app from the smaller one to the bigger one, resizing areas of the viewport causes the UI to break. Doing this fills the screen with black bars, and pop-ups from hovering never disappear.
New-Recording-24_08_2022-14_50_11.mp4

Exact steps for others to reproduce the error

From startup, drag Blender to a monitor with a smaller resolution.
drag it back to the monitor with the higher resolution.
click and drag the black area to resize a portion of the viewport.

It seems to depend on the layout in the file, so use the file attached below.
Ghost.blend

**System Information** Operating system: Windows 10 Graphics card: Nvidia GTX 1060 **Blender Version** Broken: Blender 3.2.2 **Short description of error** I have two monitors with different resolutions. When I drag the Blender app from the smaller one to the bigger one, resizing areas of the viewport causes the UI to break. Doing this fills the screen with black bars, and pop-ups from hovering never disappear. [New-Recording-24_08_2022-14_50_11.mp4](https://archive.blender.org/developer/F13417374/New-Recording-24_08_2022-14_50_11.mp4) **Exact steps for others to reproduce the error** - From startup, drag Blender to a monitor with a smaller resolution. - drag it back to the monitor with the higher resolution. - click and drag the black area to resize a portion of the viewport. It seems to depend on the layout in the file, so use the file attached below. [Ghost.blend](https://archive.blender.org/developer/F13415409/Ghost.blend)

Artur commented

2022-08-24 19:52:41 +02:00

Added subscriber: @AzulDelta

Artur commented

2022-08-24 20:00:44 +02:00

Huh. After replicating the bug a few more times, it stopped happening on new files. Now its happening permanently in this specific file I was working on:
Ghost.blend

Huh. After replicating the bug a few more times, it stopped happening on new files. Now its happening permanently in this specific file I was working on: [Ghost.blend](https://archive.blender.org/developer/F13415409/Ghost.blend)

Pratik Borhade commented

2022-08-25 05:29:31 +02:00

Added subscriber: @PratikPB2123

Campbell Barton changed title from ~~UI breaks after switching app between monitors~~ to UI breaks after switching app between monitors (WIN32)

2022-08-25 08:18:43 +02:00

Omar Emara changed title from ~~UI breaks after switching app between monitors (WIN32)~~ to UI breaks after moving the Blender window between monitors of different resolutions

2022-08-29 12:56:11 +02:00

Richard Antalik commented

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

Added subscribers: @Harley, @iss

Richard Antalik commented

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

I am able to reproduce with provided file, but not from scratch

@Harley I think you were looking for case like this (in context of having area split lines present that could not be removed), but could be completely different issue.

I am able to reproduce with provided file, but not from scratch @Harley I think you were looking for case like this (in context of having area split lines present that could not be removed), but could be completely different issue.

Harley Acheson self-assigned this 2022-08-30 23:23:01 +02:00

Harley Acheson commented

2022-08-30 23:23:01 +02:00

@iss - I think you were looking for case like this (in context of having area split lines present that could not be removed), but could be completely different issue.

Yes, this seems to be caused by joining areas in a way that left them invalid in this file. Which is why we can't replicate without this file. We had one other report of this type of thing since complex joining was added in Blender 3.0 with D8084: UI: Join or Close Any Area, but I have yet to find any steps that can be recreated to do this at will.

I'll take a closer look at this file to see if there are any clues.

@AzulDelta - I would love it if you can ever create a list of steps that start with Factory layout and result in this type of error. If I can follow steps that create this error I can definitely fix it. But it is a hard thing to figure out with just the file after the fact.

@iss - I think you were looking for case like this (in context of having area split lines present that could not be removed), but could be completely different issue. Yes, this *seems* to be caused by joining areas in a way that left them invalid in this file. Which is why we can't replicate without this file. We had one other report of this type of thing since complex joining was added in Blender 3.0 with [D8084: UI: Join or Close Any Area](https://archive.blender.org/developer/D8084), but I have yet to find any steps that can be recreated to do this at will. I'll take a closer look at this file to see if there are any clues. @AzulDelta - I would love it if you can ever create a list of steps that start with Factory layout and result in this type of error. If I can follow steps that create this error I can definitely fix it. But it is a hard thing to figure out with just the file after the fact.

Pratik Borhade commented

2022-09-02 03:15:46 +02:00

Changed status from 'Needs Triage' to: 'Needs User Info'

Richard Antalik commented

2022-11-11 19:39:43 +01:00

@Harley Did you make progress on this report? Since there is no response I am wondering whether this can be confirmed or we shall close the report.

Harley Acheson commented

2022-11-11 20:12:24 +01:00

@iss - Did you make progress on this report?

This report ended up being about a singular blend file that was saved in a state with invalid regions after prior area joins.

So the report, as is, doesn't really describe the underlying issue. Basically the bug is really that a blend file can end up with invalid areas after joining in some circumstances. There are two ways to cause this, one addressed, the other not yet.

It was the case that our values for minimum area sizes were not scaled by UI scale. So it was possible to move a window between monitors of differing scale, adjust area sizes, then do a join where there was an area involved that was smaller than our minimum sizes. This was corrected in {d26a0be968e0}
It is currently possible to create areas that are below our minimum allowed sizes by sizing a window to wider than one monitor width (so spanning more than one monitor at once), then resize an area to minimum width, then scale the window itself back to fit on a single monitor. Our area scaling code would then make that small area below our minimum and allow it to break some joins. This is not addressed. I tried to do so in D15872: Fix #100772: Area AREAMINX on Window Resize but the approach was not approved. I'm hoping to revisit that during the 3.5 release cycle.

In a nutshell the chances of creating invalid areas is quite low and we have only had a few reports of this happening in the time since allowing complex joining (between areas of differing size). The most-likely vector for this has been fixed, but the less-likely way is still possible but is unlikely to occur in practice.

> @iss - Did you make progress on this report? This report ended up being about a singular blend file that was saved in a state with invalid regions after prior area joins. So the report, as is, doesn't really describe the underlying issue. Basically the bug is really that a blend file can end up with invalid areas after joining in some circumstances. There are two ways to cause this, one addressed, the other not yet. 1. It was the case that our values for minimum area sizes were not scaled by UI scale. So it was possible to move a window between monitors of differing scale, adjust area sizes, then do a join where there was an area involved that was smaller than our minimum sizes. This was corrected in {d26a0be968e0} 2. It is currently possible to create areas that are below our minimum allowed sizes by sizing a window to wider than one monitor width (so spanning more than one monitor at once), then resize an area to minimum width, then scale the window itself back to fit on a single monitor. Our area scaling code would then make that small area below our minimum and allow it to break some joins. This is not addressed. I tried to do so in [D15872: Fix #100772: Area AREAMINX on Window Resize](https://archive.blender.org/developer/D15872) but the approach was not approved. I'm *hoping* to revisit that during the 3.5 release cycle. In a nutshell the chances of creating invalid areas is quite low and we have only had a few reports of this happening in the time since allowing complex joining (between areas of differing size). The most-likely vector for this has been fixed, but the less-likely way is still possible but is unlikely to occur in practice.

Richard Antalik commented

2022-11-11 21:45:53 +01:00

Changed status from 'Needs User Info' to: 'Archived'

Richard Antalik closed this issue

2022-11-11 21:45:53 +01:00

Richard Antalik commented

2022-11-11 21:45:53 +01:00

Thanks for info, seems that what could be deduced from the report was, so since there is no more info provided by user, I will close this report.

@AzulDelta if you can provide more information feel free to do so either here on in new report.

Thanks for info, seems that what could be deduced from the report was, so since there is no more info provided by user, I will close this report. @AzulDelta if you can provide more information feel free to do so either here on in new report.

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

UI breaks after moving the Blender window between monitors of different resolutions #100618