I'm trying to build a tool with Godot, and I've created a header for a list control.

The problem is that whenever I resize the window, the header is redrawn all out of whack. It gets stretched, moved and flickers before finally drawing properly when I finish resizing the window.

It looks really bad! It's especially bad because it's doing all this redrawing needlessly: It happens primarily when the window height is being resized, which shouldn't affect the header at all because it's only allowed to resize horizontally.

I have a screen recording of it happening, but this forum isn't letting me attach it to this post. And... I apparently can't post still image screenshots of the hierarchy or how it's laid out onscreen either.

I'm using: Godot 3.2.1 Stable elementaryOS 5.1.5 (ubuntu 18.04) with all updates Ryzen 3900X Radeon RX590 8GB

Here is what my control hierarchy looks like (edit: updated with info about settings):

HBoxContainer (Layout == Top Wide)
	TextureRect
	VBoxContainer (HSizeFlags == Fill & Exp)
		TextureRect (the top hilite line.  Scale == Tile; HSizeFlags == Fill)
		HBoxContainer (HSizeFlags == Fill)
			TextureRect
			TextureButton
			TextureRect2
			TextureRect3 ("Col 1" label)
			TextureRect4 (exp rgn of "col 1". Scale == Tile; HSizeFlags == Fill & Exp)
			TextureRect5
			TextureRect6
			TextureRect7
			TextureRect8
			TextureRect9
			TextureRect10
			TextureRect11
			TextureRect12
			TextureRect13
			TextureRect14
		TextureRect2 (bottom shade line. Scale == Tile; HSizeFlags == Fill)
		TextureRect3 (bottom border line. Scale == Tile; HSizeFlags == Fill)
	TextureRect2
	MenuButton
		Icon

Edit: Trying to add a couple of stills using the "Add Images" button below.

Here is a screen shot of the control hierarchy:

Edit: Added more system info, and updated control hierarchy lists above to include info about scaling and size flags. Unless noted, all controls have their scale set to Keep Aspect, and their size flags are unset.

Here is the header I'm trying to make for my list/tree (the "Layout" option for the root item is "Top Wide"):

@AspiringGameDev said: I have a screen recording of it happening, but this forum isn't letting me attach it to this post. And... I apparently can't post still image screenshots of the hierarchy or how it's laid out onscreen either.

Strange. I'm not sure why image uploading is not working. Does the "Add Images" button work? That should use Imgur to post the images, which should work.

I had been trying to use the "Add Image" menu in the BBCode bar that's above the editing area.

I just tried the "Add Images" button below, but uploading the gif version doesn't work because the limit is only 10MB or so, and the recording is 33.5MB. It would be nice if I could upload the mp4 version, it's only 577.3KB.

(If the add image button above doesn't work, it really ought to be removed/disabled, just to avoid confusion.)

I believe you can upload to gifycat and the forum should be able to embed from the link.

Looking at the image, a few things could be causing the issue:

How are you handling the position of the top bar? Are you using one of the layouts in the dropdown that appears when you select a Control node? Edit: nevermind, I saw it is top wide. Is there anything else attached to the top bar, script or otherwise, that could potentially be affecting the position or scaling?

When resizing the window, Godot has to redraw the scene. This is because of how graphics APIs work, as it needs to draw the newly seen/available space, and this requires redrawing the entire window. The gap in between the non-resized image and the resized image being rendered could cause some of the jumping, though I do not think it would be as dramatic as what is seen in the video. What are the settings for your window mode? Have you tried setting the aspect mode to expand, keep, etc? Maybe something there is causing the issue.

I've edited the first post to add more system info, and updated the control hierarchy lists to include info about the scaling and size flags. Unless noted, all controls have their scale set to Keep Aspect, and their size flags are unset.

The redraw looks like it's being done very inefficiently. There's plenty of layout information to allow godot to determine what actually needs to be redrawn. It seems to be first moving the entire old window content down & left to follow the bottom and right edges, and then erasing and redrawing the entire upper area. That's a really bad way to redraw a window being resized. At least that's what it looks very much like it's doing, I haven't looked at the source code for it.

Keep aspect might be the problem. You might want to have the height of the bar be relative to window height and the width to be relative to the width, but the height and width to be independent of each other. Then the contents should probably be sized according to the height.

I've tried changing the scaling factor. It doesn't change the behavior at all.

I want the height of the bar to be fixed, not expanding/relative to the height of the window. This is for a tool, not a game.

I just tried changing the Godot editor's window from fullscreen to resizeable, and then started resizing it. It exhibits the same problem! However, when live-adjusting control size by sliding a vertical separator up and down, no visual artifacts happen at all. That way of resizing/revealing/hiding controls within a fixed size window is smooth as glass!

hmm, yeah then having the height be dependent on the icon size makes the mist most sense.

Are you updating/redrawing your bar in _process() or leaving it up to godot to update it?

I haven't written any code so far, so everything is being updated by godot. I've just been getting the hang of building gui layouts, making separate projects for the different aspects of the gui for the tool and working out any bugs before I try putting everything together.

Out of curiosity, I tried importing the project into a build of the 4.0/master branch from github and it imported ok. But resizing the window doesn't cause any updates/redraws at all. So I guess that functionality in 4.0 isn't implemented or finished being rewritten yet.

It could be a bug, though I'm not sure. Can you make a minimum replication project? Just something super quick that hopefully will show the same issue in a new project, if that's not too much trouble. That way, we can see if we can reproduce the issue. Additionally, if it is a bug, you will already have a project to post on the GitHub issue.

Here you go!

It's already a minimal project (see my post two posts up), so I just compressed and attached it here.

@AspiringGameDev said: Here you go!

It's already a minimal project (see my post two posts up), so I just compressed and attached it here.

Whoops, I guess I missed it! That's what I get for posting before I'm fully awake mentally :sweat_smile: Thanks for posting it, I'll take a look at the project later today and see if I can figure out what is going on.

@AspiringGameDev - Adding the following script makes it a little better (tested on Godot 3.2.1 Linux):

extends HBoxContainer

func _ready():
	pass

func _notification(what):
	if what == NOTIFICATION_RESIZED:
		get_tree().root.update_worlds();
		force_update_transform();
		update();

With this code, it at least doesn't suddenly flash in and out of existence. It still is not positioned perfectly though when being resized. I'm not sure if this is a bug, or a rendering limitation though. I might suggest making a GitHub issue on the matter, just to see if this is a bug or a limitation, and potentially what can be done about it. I looked through the Viewport and CanvasItem documentation, and unfortunately there doesn't seem to be anything that looks like it might help, beyond what @Megalomaniak already suggested.

Thanks! I see what you mean.

My opinion is that it's almost certainly a bug. Because when vertical resizing of controls is caused by using a vertical separator, it is smooth as glass with none of these artifacts/glitches. So there's really no reason it shouldn't be just as smooth and clean when the resizing is the result of the window being resized.

I started exploring the idea of custom drawing functions to simplify the list header, and maybe get around the problem. I created a project consisting of the example code for the CanvasItem custom drawing tutorial. Even this project exhibits the vertical flickering problem.

This made me wonder what the simplest way of reproducing the problem was. So I created an even simpler minimal project to reproduce the error: A single label (text: "Watch me flicker!", everything else left to default values) in the middle of the window. It's so simple, you can probably create it yourself faster than it would take you to download, decompress, import and run it. I put the label in the middle of the window (by dragging with the mouse) so the full effect of the problem can be easily seen: The label gets drawn above and below the correct location, depending on whether the window height is increasing or decreasing, but never off to the side.

Interestingly, the new bug demo project shows the problem in 3.2.1-stable, but not in the 4.0/master branch.

So this problem might already be fixed in the 4.0/master branch. I just tried reproducing it with both the new demo project and just the editor window, and it resizes fairly smoothly the way it should. There is still a bit of update lag on the right and bottom edges when the window is being resized quickly, but not nearly as bad as with 3.2.1-stable.

Unfortunately, this problem hasn't been fixed in the 3.2.2 update that was released today.