GUI Controls Redraw Badly While Resizing Window

AspiringGameDevAspiringGameDev Posts: 13Member
edited June 22 in GUI

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"):

Comments

  • TwistedTwiglegTwistedTwigleg Posts: 2,635Admin

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

  • AspiringGameDevAspiringGameDev Posts: 13Member

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

  • MegalomaniakMegalomaniak Posts: 2,618Admin

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

  • AspiringGameDevAspiringGameDev Posts: 13Member
  • TwistedTwiglegTwistedTwigleg Posts: 2,635Admin

    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.

  • AspiringGameDevAspiringGameDev Posts: 13Member

    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.

  • MegalomaniakMegalomaniak Posts: 2,618Admin
    edited June 22

    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.

  • AspiringGameDevAspiringGameDev Posts: 13Member

    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!

  • MegalomaniakMegalomaniak Posts: 2,618Admin
    edited June 24

    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?

  • AspiringGameDevAspiringGameDev Posts: 13Member

    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.

  • AspiringGameDevAspiringGameDev Posts: 13Member

    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.

  • TwistedTwiglegTwistedTwigleg Posts: 2,635Admin
    edited June 23

    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.

  • AspiringGameDevAspiringGameDev Posts: 13Member

    Here you go!

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

  • TwistedTwiglegTwistedTwigleg Posts: 2,635Admin
    edited June 23

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

  • TwistedTwiglegTwistedTwigleg Posts: 2,635Admin
    edited June 24

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

  • AspiringGameDevAspiringGameDev Posts: 13Member

    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.

  • AspiringGameDevAspiringGameDev Posts: 13Member
    edited July 2

    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.

  • AspiringGameDevAspiringGameDev Posts: 13Member

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

Leave a Comment

BoldItalicStrikethroughOrdered listUnordered list
Emoji
Image
Align leftAlign centerAlign rightToggle HTML viewToggle full pageToggle lights
Drop image/file