Updating the position of a GuiObject renders the change after the current frame has rendered


Here’s a video showing what I mean. The purple dots are ImageLabels that should be drawn directly over the neon bricks every frame. The video is recorded at 12 Frames per second to emphasise the issue.

Reproduction File:
ReproFrame.rbxl (49.2 KB)
It is important to note that the GUI gets updated on the RenderStep event, while the camera is updated at the Enum.RenderPriority.Camera value through RunService:BindToRenderStep()

Expected behavior

The GUI elements should update instantly on the frame the position was set. Such that the purple dots in the video above are always above the neon bricks without delay.

2 Likes

I encountered a similar issue last night where I had some delayed threads (executing after RenderStepped and after the GUI layout step, but before actual rendering). which were updating GuiObjects in a ScrollingFrame with those changes not being rendered. I’m not sure if it’s the same problem exactly though.

(The labels where I was making changes to GuiObjects were the WS_UPDATE labels.)

I found a quick fix which may work for you in the meantime: I had to force a layout update by reading GuiObject.AbsolutePosition or similar values. I’m not certain about this, but you may need to choose the GuiObject carefully so that it’s one which has been invalidated since the layout was last performed.

GuiObject.Position = ...

-- Force layout update
local _ = GuiObject.AbsolutePosition
2 Likes

This is just an acknowledgment announcement!

We’ve filed a ticket into our internal database for this issue, and will come back as soon as we have updates!

Thanks for flagging!

Hi @fireys thanks for the report. This looks very similar to:

We will look into this and hopefully have a resolution soon!

2 Likes