Page MenuHome

Empty HUD (Redo Panel)
Closed, ResolvedPublicBUG

Description

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: rBf9d0f59bed4d
Worked: version: 2.83 (sub 16), branch: master, commit date: 2020-05-12 22:10, hash: rB50ef801a79b5

Short description of error
Sometimes the Redo Panel is empty:

Exact steps for others to reproduce the error

  • Open attached file.
  • Press G to move the object and confirm

Revisions and Commits

Event Timeline

Germano Cavalcante (mano-wii) changed the task status from Needs Triage to Confirmed.Thu, May 21, 4:24 PM
Germano Cavalcante (mano-wii) changed the subtype of this task from "Report" to "Bug".

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)

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.

Maybe try with softwaregl?

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

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

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.

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.