#Jitter during Tweening location

99 messages · Page 1 of 1 (latest)

fast fossil
#

I'm having an issue where my project is jittering and causing a items to go "backwards" for a frame or two at several points during a tween. It's hard to see in the video due to FPS and the fact it only lasts for a few frames. My process and viewport render times jump up to about 20 ms on these frames. Other scenes with the same objects moving but without the Carousel do not seem to have this issue, so it appears to be related to items moving within the carousel code I have and not a more general problem with the scenes in question. I've commented out a fair bit of my animation code to try to narrow it down and i'm still seeing the issue. The code I've noted is the movement code that appears to be creating the issue.

the best way to explain it is this way: if I had a tween that would result in the item moving right 1 pixel per frame, what I'm seeing is it going from positions on each frame like such: 0, 1, 2, 3, 2, 2, 6, 7, 8, 9, 8, 11, 12, 13, 12, 12, 14, 13, 16, 17. It gets to where it's supposed to go, but the tween is not doing it smoothly. The values of scroll_horizontal, if printed every process frame, are sequential and as expected, but the items being moved on the scroll are still hicupping. The items in the scroll container are just scenes put into an Hbox container that is scrolled. Nothing fancy. I've attached one of the scenes here.

The part that gets me is that it seems to "come and go". The stutter doesn't seem to be repeatable in any meaningful way, it just randomly happens (although it happens a lot).

Screenshot_2025-09-11_123332.png image.png
fast fossil
#

I would add that this does not happen on every device. I cannot seem to replicate it on my phone or 1080ti, but my AMDintegrated/3050 laptop has it really bad.

hollow hamlet
#

Not sure why something like this would be hardware dependent. But to me it sounds like it could be caused by animating something that already gets its transform changed by a parent container.

fast fossil
#

It does feel like it's control fighting. But I couldn't figure out what would be the cause of that. And I don't understand why that wouldn't be repeatable on the other devices.

hollow hamlet
#

Wait, are you triggering part of the animation by mouse hover?

fast fossil
#

Well the laptop is a dual GPU, but I can't change it to dGPU only. But both W11, both should be technically sound. The laptop has AMD adrenaline drivers which I know have been buggy. But I don't think that's it. I still have the issue if I change to non-vulkan renderer.

#

Ummm... There is a gui_input, but I'm triggering with a mouse scroll.

#

Sorry I'm not at the computer now. I can get you better pics in a few hours.

hollow hamlet
#

Alright, the animation seems like it requires a shader. Is that correct?

fast fossil
#

But essentially I'm triggering the scroll_left() and scroll_right()

fast fossil
hollow hamlet
#

The one that allows the rotation?

fast fossil
#

No. Rotation is literally just rotating the root control element

#

The shader handles skew of the images, it's not really doing anything heavy

hollow hamlet
fast fossil
#

Actually I may have even used meshes for that element

#

Not a shader. I'll have to check

hollow hamlet
#

so 3d?

fast fossil
#

But if it's a shader, it's one I use elsewhere without issue

#

No all 2d

hollow hamlet
#

The perspective distortion seen on the flip isn't possible in 2d without a custom shader as far as i know

fast fossil
#

If I eliminate all the rotation code, I still get the flicker

#

Oh

#

Yes that is a shader.

#

Sorry. I was thinking of another element. I have a few different objects that can be put into the carousels. I have another one that is more of a static image. They both have the same issue

hollow hamlet
#

but are they both control nodes?

#

(my keyboard really doesn't want me to type "y"...)

#

Maybe this is caused by the setting that makes control nodes snap to pixels.

fast fossil
#

I included the scene tree of one of the items. It replicates even if the item being scrolled is a control and a texture child.

#

That could be....

#

I'll test that theory when I get back

#

The thing I don't understand is if I print the position of the items that are jittering, they do go up sequentially in a manner that would be expected by the tween. It's just that what I see on screen doesn't match their position in code

hollow hamlet
fast fossil
#

Each block is a new frame, printing a position or global position of an element I thought might be the issue.

hollow hamlet
#

Well i can't really do anything with those numbers

#

Given that in only happens on certain devices i think you should report it as a bug. Something is definitely not working as intended here.

fast fossil
#

I was just posting those to show that I've checked that the code seems to be tweening the scroll/position properly

hollow hamlet
fast fossil
#

So I've been able to test a bunch of stuff and created a new project to make sure I wasn't losing my mind.

#

Here is the entirety of the new script:

image.png
hollow hamlet
fast fossil
#

no, but i wasn't sure if automatic resizing was causing the issue. It was not.

#

So the original code is scrolling a scrollcontainer, and then moving the images relative to how far the item is from the center of the scroll container based on some curves.

#

This new code takes all that crap out and just uses a ColorRect

#

I'm getting the same problem

#

if you scroll the mouse wheel fast in either direction, the color rects flicker

#

it almost looks like screen tearing...

#

OMFG that was it

#

I turned of VSync in the project settings and now it works in my game

#

@hollow hamlet So many thanks! At least now I know what I'm dealing with.

hollow hamlet
#

good to hear, but you said that the project you sent me has the same issue, but it has vsync enabled.

#

Here it is on my end. do you mean the thing at the end when it slows down to a crawl, or am i unable to reproduce the issue?

fast fossil
#

When I disable it, it fixes my issue.

I'm guessing you are unable to reproduce because VSync works for you. That would explain why I couldn't reproduce it on some devices. However, it was really bad on my laptop.

#

I'm guessing I have some hardware limitation?

#

but if I disable it, it's buttery smooth

#

It's very helpful to know that it's not my code/scenes that are the cause

fast fossil
#

It also seems that setting it to compatibility renderer also fixes it.

#

And.... Now it's back

#

Wtf

hollow hamlet
fast fossil
#

Ah nm, I think it might just not have saved the setting.

hollow hamlet
#

well to change the render mode you have to restart the editor

fast fossil
#

Yeah, apparently for vsync too

#

Anyways. That fixed it

#

I suspect the issue is related to my dual GPU setup. Godot runs on the Nvidia, but I can't turn off the AMD one.

#

I think it's related to that bug report you posted, it sounds like what's going on here.

#

Frames being shown out of order and then screen tearing

hollow hamlet
#

i mean, preventing screen tearing is pretty much the only job vsync has. so something is definitely going wrong.

fast fossil
#

i'm going to try running it undocked to see what happens

hollow hamlet
# fast fossil Yeah, apparently for vsync too

that should also not be the case. you are supposed to be able to change that setting even during the game (like most games allow you to in the settings). so it not being possible is probably part of the bug.

fast fossil
#

omfg, so if i undock it, I have control over the GPU. If I set it to run on the integrated graphics, I get zero screen tearing.

#

so I can't recreated it with either GPU if i'm not docked.... I wonder if it's pulling information from the laptop display instead of the monitor? If the data output is wrong frequency or something, that could cause an issue like this

hollow hamlet
#

i'm not that experienced when it comes to hardware, but the integrated monitor of a laptop being handled differently sounds plausible

fast fossil
#

so the laptop monitor runs flawless at 3072x1920 @ 120 hz

however the external monitor is a 3440x1440 @ 100 hz cap

#

YES, i figured it out

#

so Godot wants to use my dGPU. However when I'm docked the laptop automatically uses the amd GPU to output the display

#

I'm guessing there's an issue here due to the differences in refresh rates

#

"Let windows Decide" is the problem

hollow hamlet
#

always windows...

fast fossil
#

So if I force windows to use the integrated GPU for Godot (which is the one outputing to the monitor), I don't have any issues

hollow hamlet
fast fossil
#

Yeah, but I'm trying to figure out exaclty what the issue is

#

So the issue seems to be when I use the Nvidia GPU to run Godot, but the AMD GPU is outputting to the external monitor

#

I'm getting sync issues with vsync on

#

lowering the refresh rate doesn't seem to make a difference

#

no matter what I do, the only thing that seems to work is that I manually override it in windows to tell it to use my AMD card (the one that outputs to the monitor)

#

when I'm undocked, it doesn't seem to make a difference

#

I think what is going on is that the default of the laptop is to process on the Nvidia, but display to the AMD. basically split the workload. However, when godot runs on the Nvidia, it's assuming the output is running at the same rate as the GPU (120 hz), so it renders at that speed. The AMD framerate is limited to 85 hz because of the ultrawide monitor, and boom, that's the issue. Tearing.

#

Yeah, I just tested all the GPU settings in the Nvidia control panel. Nothing works. Only thing that seems to work is changing it in the windows to use the AMD

#

or just disabling sync in the editor

hollow hamlet
#

spliting the workload does sound like something that could cause sync issues like frame skips. i'm just confused that you have to go out of your way to not use 2 gpus for different things.

fast fossil
#

I think Godot renderer might be making the assumption here