Property tooltips are cut-off on Linux (DisplayServer regression)

[mordae]

---

Bugsquad note: This issue has been confirmed several times already. No need to confirm it further.

---

Godot version

v4.0.alpha9.official [fc18891]

System information

Fedora 35, Vulkan, RX Vega 64

Issue description

Property tool tips are cut-off. It seems as if the buffer is too short.
The tool tip window itself is sized properly and different for every property as it should be.

Steps to reproduce

1. Open new project.
2. Open project settings.
3. Hover on property.

Minimal reproduction project

No response

Bugsquad edit (keywords for easier searching): cut, clip, cutoff

[mordae]

I forgot to add, this is with GNOME at Xorg. Wayland disabled.

[jgillich]

Same here, issue did not exist in alpha 8.

Fedora Silverblue 36, Ryzen 2400G, X11/GNOME (edit: also on Wayland)

[RechieKho]

For me (v4.0.alpha.custom_build [0df0a07]), it works well, no such issue.

Debian, X11/GNOME

[Mr-L-oof]

I use wayland with swaywm and I've been encountering this issue as well.

[mordae]

Still happens in v4.0.alpha.custom_build.136f84fc3.

[bimmlerd]

I took a look at this, also on sway/wayland. There the issue is even more clear, as the 'cut-off' part is simply black. In my case, I'm using the property tooltips of the inspector as a reproducer.

I'm not sure whether this really is a DisplayServer regression- the tooltip_popup misreports its vertical minimum size in viewport.cpp:1323. In my case, it reports (on my machine/screen) a height of 54 px, which is exactly the visible part.

Going down the rabbit hole, the EditorHelpBit constructor sets a vertical custom_minimum_size of 50px, add the 4px minimum size of the panel (https://github.com/godotengine/godot/blob/master/scene/gui/popup.cpp#L208) and we get to our 54px. Clearly, however, instead of the custom minimum size, the RichTextLabel contained within the panel should be dictating the size, since it would require a larger vertical minimum size.

Hypothesis one is thus that somewhere in the hierarchy of controls, something is reporting a wrong/stale (caching is involved) height. The other is that there is a race condition, since upon closer inspection, the black part of the popup is exactly as large as the popup should be.

EDIT: So digging a bit further I think this is an unfortunate interplay between the RichTextLabel only shaping, and thus determining its proper size upon a NOTIFICATION_DRAW, and the viewport code setting the size of the popup rect before drawing. I have no clue how to resolve that 🙃 Willing to try to fix if somebody can tell me what the proper approach would be, though.

Maybe @Calinou knows how this is supposed to work/knows who would know?

[Calinou]

Maybe @Calinou knows how this is supposed to work/knows who would know?

I haven't worked much on the GUI system. Perhaps @bruvzg or @KoBeWi will know a better solution than me.

[KoBeWi]

Can't reproduce on Windows. All reports so far pretty much confirm this only exists on Linux.

[xix-xeaon]

Confirmed X11/KDE. Also happens with the properties in the inspector.

[blipk]

Confirm that this is still persistent in v4.0.alpha14 on Gnome Wayland

[akien-mga]

See also duplicate #62496 for some details. Notably:

#62496 (comment)

I can reproduce it on Mageia 9, it's a regression introduced between 4.0 alpha 8 (good) and alpha 9 (bad).
A similar issue existed in earlier alphas and was fixed a few months ago, it seems something broke that fix again.

#62496 (comment)

The issue seems to happen only with multiple window support enabled, because otherwise it doesn't happen, as can be seen below.

[akien-mga]

@bruvzg Seems like my hunch in #62496 (comment) was correct, I finally took the time to bisect between 4.0 alpha 8 and alpha 9, and I landed on cfcdfc3.

$ git bisect log
git bisect start
# status: waiting for both good and bad commits
# good: [917fd65748957304c987414c63d54ef4f6972394] Merge pull request #60929 from bruvzg/macos_ios_includes
git bisect good 917fd65748957304c987414c63d54ef4f6972394
# status: waiting for bad commit, 1 good commit known
# bad: [d9daf3869f27e2afdacb2744168052ce0d4ae43b] Merge pull request #61607 from smix8/navigation_agent_height_offset_doc_4.x
git bisect bad d9daf3869f27e2afdacb2744168052ce0d4ae43b
# bad: [b9bb3de6a1680693f8698926859ee3543422c0f2] Merge pull request #61142 from bruvzg/rtl_threaded
git bisect bad b9bb3de6a1680693f8698926859ee3543422c0f2
# good: [0497b67bec0f545727e2e3c0a8b03d52be916b81] Merge pull request #60130 from fire-forge/theme-node-names
git bisect good 0497b67bec0f545727e2e3c0a8b03d52be916b81
# good: [f87e5c481d02f6b3000cd09c17444db93d12be2c] Merge pull request #61127 from vnen/read-only-array
git bisect good f87e5c481d02f6b3000cd09c17444db93d12be2c
# good: [5b3d5962858dbd096ddfe01bc214cdfc55fef473] Merge pull request #60774 from TokageItLab/root-seek-mode
git bisect good 5b3d5962858dbd096ddfe01bc214cdfc55fef473
# good: [3b09e90ae77dfe8b6ba5ea00cfc409f3c69fa2cc] Merge pull request #61154 from KoBeWi/call_deferred_helps,_as_always
git bisect good 3b09e90ae77dfe8b6ba5ea00cfc409f3c69fa2cc
# good: [c0d189fbb85cbfc1b7e91e38d882e123730f7e98] Merge pull request #60955 from pfertyk/issue-60668-fix-get-breakpointed-lines-crash
git bisect good c0d189fbb85cbfc1b7e91e38d882e123730f7e98
# good: [d8093dd27363384c7196dbff7e485f0df2b11894] Merge pull request #61173 from LightningAA/update-set-iterators
git bisect good d8093dd27363384c7196dbff7e485f0df2b11894
# good: [5dc754a34894036344b4f56f6370280d43aa2da5] Merge pull request #61189 from timothyqiu/typo-fix
git bisect good 5dc754a34894036344b4f56f6370280d43aa2da5
# bad: [cfcdfc38e275d8766e69621a001422030e515173] [RTL] Add support for shaping in background thread.
git bisect bad cfcdfc38e275d8766e69621a001422030e515173
# first bad commit: [cfcdfc38e275d8766e69621a001422030e515173] [RTL] Add support for shaping in background thread.

(That was a long bisect when I had found the culprit commit on the first step already :P)

[bruvzg]

Seems like my hunch in #62496 (comment) was correct, I finally took the time to bisect between 4.0 alpha 8 and alpha 9, and I landed on cfcdfc3.

OK, I have checked this change again, tooltips do not use threaded mode, but I think I see what might be causing it - #64783. I'll test it tomorrow, since it's not reproducible on macOS and Windows and there might be underlying bug in the X11 window handling as well.