Empty HUD (Redo Panel) #76940

Closed
opened 2020-05-21 16:24:29 +02:00 by Germano Cavalcante · 12 comments

System Information
Operating system: Windows-10-10.0.19041-SP0 64 Bits
Graphics card: Radeon (TM) RX 480 Graphics ATI Technologies Inc. 4.5.13586 Core Profile Context 19.50.01.05 26.20.15001.5006

Blender Version
Broken: version: 2.90 (sub 1), branch: master, commit date: 2020-05-12 22:14, hash: f9d0f59bed
Worked: version: 2.83 (sub 16), branch: master, commit date: 2020-05-12 22:10, hash: 50ef801a79

Short description of error
Sometimes the Redo Panel is empty:
empty_hud.png

Exact steps for others to reproduce the error

  • Open attached file.
  • Press G to move the object and confirm
    redo_bug.blend
**System Information** Operating system: Windows-10-10.0.19041-SP0 64 Bits Graphics card: Radeon (TM) RX 480 Graphics ATI Technologies Inc. 4.5.13586 Core Profile Context 19.50.01.05 26.20.15001.5006 **Blender Version** Broken: version: 2.90 (sub 1), branch: master, commit date: 2020-05-12 22:14, hash: `f9d0f59bed` Worked: version: 2.83 (sub 16), branch: master, commit date: 2020-05-12 22:10, hash: `50ef801a79` **Short description of error** Sometimes the Redo Panel is empty: ![empty_hud.png](https://archive.blender.org/developer/F8546493/empty_hud.png) **Exact steps for others to reproduce the error** - Open attached file. - Press G to move the object and confirm [redo_bug.blend](https://archive.blender.org/developer/F8546501/redo_bug.blend)
Author
Member

Added subscriber: @mano-wii

Added subscriber: @mano-wii
Author
Member

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

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

Added subscriber: @JulianEisel

Added subscriber: @JulianEisel
Member

Can't recreate this with master.
Tested with global undo off too, but that didn't change anything either.

Maybe try with softwaregl? (I don't actually know if you can still do that on Windows nowadays)

Can't recreate this with master. Tested with global undo off too, but that didn't change anything either. Maybe try with softwaregl? (I don't actually know if you can still do that on Windows nowadays)
Member

Added subscriber: @HooglyBoogly

Added subscriber: @HooglyBoogly
Member

I can reproduce this, that's odd.

The redo panel doesn't respond at all. Even clicking the expand arrow just places the 3D cursor below it.

Moving either of the two objects makes this happen, but moving either of them a second time doesn't.

I can reproduce this, that's odd. The redo panel doesn't respond at all. Even clicking the expand arrow just places the 3D cursor below it. Moving either of the two objects makes this happen, but moving either of them a second time doesn't.
Author
Member

In #76940#936218, @JulianEisel wrote:
Maybe try with softwaregl?

I can still replicate.
Nothing changes with softwaregl and Factory Settings.
Maybe it's a windows specific problem?

> In #76940#936218, @JulianEisel wrote: > Maybe try with softwaregl? I can still replicate. Nothing changes with softwaregl and Factory Settings. Maybe it's a windows specific problem?
Member

I'm on Linux. I can look into it in a bit.

I'm on Linux. I can look into it in a bit.
Member

Was able to reproduce it on Linux too (previously tried on macOS).

This is probably caused by bad initialization of area/region coordinates. There are some subtle differences between how OSes send screen size events, that may kick in here.
And indeed, forcing a re-init of coordinates by dragging an area edge or changing the window size brings back the label.

Was able to reproduce it on Linux too (previously tried on macOS). This is probably caused by bad initialization of area/region coordinates. There are some subtle differences between how OSes send screen size events, that may kick in here. And indeed, forcing a re-init of coordinates by dragging an area edge or changing the window size brings back the label.

This issue was referenced by 3bc15c097c

This issue was referenced by 3bc15c097c6492559d416a4eafecb7e6936a80b8
Member

Changed status from 'Confirmed' to: 'Resolved'

Changed status from 'Confirmed' to: 'Resolved'
Julian Eisel self-assigned this 2020-05-22 18:43:20 +02:00
Member

The region coordinates were only updated if the newly calculated dimensions differed from what was stored in the region. So if the file was re-opened on a different effective DPI (like I did first) the region coordinates would be set properly.
Now they are always updated when visibility changes.

The region coordinates were only updated if the newly calculated dimensions differed from what was stored in the region. So if the file was re-opened on a different effective DPI (like I did first) the region coordinates would be set properly. Now they are always updated when visibility changes.
Sign in to join this conversation.
4 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: blender/blender#76940
No description provided.