GUI Controls Redraw Badly While Resizing Window

This is a READ-ONLY snapshot of the Godot Community Forums when TwistedTwigleg was the owner, which is hosted for archival reasons only. The current Godot Community Forums can be found here.

Some links may point to external websites, including the current Godot Community Forums. These websites are not associated with TwistedTwigleg.

GUI Controls Redraw Badly While Resizing Window

AspiringGameDev

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.

Megalomaniak

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.

AspiringGameDev

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!

Megalomaniak

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?

AspiringGameDev

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.

Megalomaniak

https://docs.godotengine.org/en/stable/classes/class_canvasitem.html#class-canvasitem-method-force-update-transform Caught my eye, might be relevant.

https://docs.godotengine.org/en/stable/classes/class_canvasitem.html#class-canvasitem-method-update and this is for manually telling a canvas item to update.

AspiringGameDev

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.

TwistedTwigleg

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.

AspiringGameDev

Here you go!

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

TwistedTwigleg

@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.

TwistedTwigleg

@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.

AspiringGameDev

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.

AspiringGameDev

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.

AspiringGameDev

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