Draw issue with focus in UI elements

[rm-code]

Godot version

4.0.rc6.mono.official

System information

macOS 12.0.1

Issue description

Just a minor visual issue.

When opening an empty directory the focus highlight is drawn incorrectly. It looks like the UI is drawing a smaller rectangle within the main rect:

This behavior also changes when you hover over other items in the view, so I'm not sure if this a general issue with the focus highlighting or just an issue in the directory view:

Steps to reproduce

1. New Project
2. Browse
3. Create Folder
4. Click or Tab to set focus on the empty directory view

Minimal reproduction project

N/A

[dalexeev]

I confirm this. Note that the bug is reproduced not in all dialogs.

Project Manager - Scan:

Open Scene:

[rm-code]

The issue isn't limited to the file dialogues. Here are examples of the issue on non-empty UI screens:

[Calinou]

This is not a rendering issue, but an issue with the GUI system. This is the IME (input method editor) having its focus outline visible at all times.

[a690089735]

downloading the export template

When I was downloading the export template, I accidentally clicked on the bottom box and it started flashing. If I clicked a few more times, it would flash faster

https://github.com/godotengine/godot/assets/34900141/73cf9186-f021-42d4-8fbc-88e29f0e08ce

[dardasaba6]

Also experiencing this in 4.1 RC1 on Linux Mint:

[dalexeev]

• See also #71213. There is some discussion that might be useful.

• #79652:

[dalexeev]

As stated in #71213, the bug is reproducible with the Compatibility renderer. I confirm that the bug is reproducible in 4.1.1 and the current master in Compatibility mode.

[lawnjelly]

An MRP would probably really help investigate this, if someone can get it to trigger in a simple project. Speaking from experience debugging the editor GUI in 3.x, there is a lot going on, so the first step is usually to simplify it down to the bare minimum draw items to create the bug. It probably just needs some GUI control.

It could be a problem in the GLES3 backend, or the GUI code (even if Vulkan is behaving ok).

EDIT: Just to reiterate, this is a request for an MRP that isn't the editor. i.e. Identify the UI items in use, recreate them in a simple project and see if you can reproduce. This is usually possible (not necessarily always) because the editor is made with Godot UI items. This is usually the easiest way to track down UI rendering bugs.

[dalexeev]

An MRP would probably really help investigate this

This is an editor issue. Steps to reproduce:

1. Create a new project.
2. Select Compatibility renderer and restart the editor.
3. Open Project Settings and click on ItemList/Tree in any tab.

One more screenshot

[WhalesState]

I have tried to add a breakpoint inside draw_rect and draw_stylebox functions in CanvasItem and RenderingServer equivalent functions with no luck on identifying where's the code that is responsible to focus the Editor's UI, also since there are no other's issue related to TreeItem then we can identify this as an Editor only issue, the issue Mostly happens with the calculation of the Control's position and size, and the appearance of another focus rect means that it was meant to focus both the Current Panel and the Current pressed UI element at same time. if it works with two focus rects in vulkan correctly then we need to use #ifdef to make opengl es 3.0 behave differently else if it only shows one focus rect in vulkan then we need to identify why the other rect is drawing again and to fix this issue.

[HolySkyMin]

Here is MRP of the problem, which is reproduced in-game. MRP.zip

The problem seems to arise when ItemList and Tree (there may be more, but at least not Button and LineEdit) are inside non-main Window. As seen in video, focus graphic in main window is also being shown in another window. (You can even see that bugged graphic moves smoothly if you're lucky enough(?))

https://github.com/godotengine/godot/assets/30334834/f3d80d34-5feb-4540-a244-df112e0f680f

[WhalesState]

Here is MRP of the problem, which is reproduced in-game. MRP.zip

The problem seems to arise when ItemList and Tree (there may be more, but at least not Button and LineEdit) are inside non-main Window. As seen in video, focus graphic in main window is also being shown in another window. (You can even see that bugged graphic moves smoothly if you're lucky enough(?))

weird_window.mp4

Tested this, it's only Tree which is causing this issue.

[WhalesState]

check this

after commenting the focus line in tree.cpp, it appears to be drawing an extra panel and it's not the tree bg panel, i will make a panel with a different color for each stylebox to see which one is causing the issue.

The extra panel is not related to this Tree Node but it's another Tree bg panel since it's using the Tree bg panel but not the current Tree node bg panel.

this one is overriding the bg panel of the Tree node.

https://github.com/godotengine/godot/assets/53877170/27706b24-ff03-4bf2-ba05-9f5d87f5e923

this one is using a theme to define the default Tree bg panel.

[HolySkyMin]

Investigated this more and these are what I've found out:

• This problem occurs at Tree, empty ItemList and empty RichTextLabel.

  • ItemList and RichTextLabel with contents doesn't seem to have problem.
  • Tree, however, behaves way more stranger. With contents, it draws another focus stylebox where ScrollBar was last visible when it gets resized.

• The problem is that focus stylebox is being drawn twice, first one is 'proper' drawing while second one is 'wrong'.

  

  When they are empty, for some reason, it seems that when drawing focus graphic they grab main window's focused control and draw another stylebox from its position. Sometimes even the main window control's position update is applied(it happens so rarely that I couldn't record it).

  But this is not 100% guaranteed: It can appear in different position with different corner.

  https://github.com/godotengine/godot/assets/30334834/57d54c48-caf7-4cdd-a812-0bf4c02375c2

  See the flickering? It's switching frame by frame between two states! (This happens randomly so I don't know why)

  https://github.com/godotengine/godot/assets/30334834/c98e77ad-39e2-4ab3-be56-be6382fd9c23

  And Tree behaves like this...

These all are being found in sub Window, but maybe it could arise even in main window when they can be resized.

Looking into the code, I found that only these controls call RenderingServer::canvas_item_add_clip_ignore() when drawing their focus stylebox. Maybe this could be reason?

[WhalesState]

Looking into the code, I found that only these controls call RenderingServer::canvas_item_add_clip_ignore() when drawing their focus stylebox. Maybe this could be reason?

I can say yes, and those lines are needed because the ScrollContainer will clip the focus stylebox, what we can do is adding a MarginContainer inside the ScrollContainer so we can have some margins to draw the focus stylebox to avoid using those lines or to define content margins inside ScrollContainer.

like this:

[HolySkyMin]

I can say yes, and those lines are needed because the ScrollContainer will clip the focus stylebox,

I agree. It definitely needs, and I couldn't find any logic mistakes in GUI side codes. Logically it's just adding CLIP_IGNORE command on and off before and after POLYGON command to the renderer(may be wrong considering my shallow knowledge about whole codes), and other renderers are doing this well.

So I think RenderingServer::canvas_item_add_clip_ignore() and related rendering code seems to be malfunctioning in this case. I hope someone else take a look into that because I don't have enough knowledge about rendering.

EDIT: Updated MRP. MRPP.zip

[boruok]

could this happen because engine can't calculate right values from stylebox? stylebox class had some changes before they are separated into diff files.

[WhalesState]

So I think RenderingServer::canvas_item_add_clip_ignore() and related rendering code seems to be malfunctioning in this case. I hope someone else take a look into that because I don't have enough knowledge about rendering.

Maybe the first draw call of the Panel before applying it's Stylebox and position is polluting the other draw calls, if there's another way to clean the GL renderer before drawing again then it will be a good fix or we add custom content margins for ScrollContainer and we allow the users to change it freely.

or the GL stylebox drawing needs a fix because this doesn't happen in Vulkan.

[filipworksdev]

Hi everyone. I am on Windows 10 and integrated Iris Xe 96EU GPU. I use Compatibility OpenGL backend. I started seeing this happen after I added a Tree into the hud. To me it seems to happen when Tree overlaps another control. It seems to draw a border around the last overlappign control. Also strangely 3D rendering/Camera seems to affect this because the lines vanish when I point the camera in specific direction in game.