Inconsistent SurfaceGui adornee overshooting behaviour between Roblox clients when CanvasSize is small

Reproduction Steps

This issue occurs with the rendering of SurfaceGuis which are AlwaysOnTop, in FixedSize mode, and have a small CanvasSize.
The attached file contains SurfaceGuis with a small CanvasSize on the Y axis.

surfacegui_overshoot_bug.rbxl (38.0 KB)

System info (expected overshooting behaviour):
AMD Ryzen 5 2600X Six-Core 3.6 GHz
NVIDIA GeForce RTX 2070. Driver version 30.0.15.1215
Memory 16 GB

System info (inconsistent overshooting behaviour):
Intel Core i9-10900K 3.70 GHz
NVIDIA GeForce RTX 2080 Ti. Driver version 30.0.15.1295
Memory 64 GB

Expected Behavior

The SurfaceGuis should
a) never overshoot their adornee if CanvasSize on one axis is smaller than 1
OR
b) have consistent overshooting behaviour across different clients.

Here is a visual example of what b) should look like on both clients:



Actual Behavior

The SurfaceGuis overshoot the adornee when CanvasSize is smaller than 1. If the overshooting itself is not a bug, then I assume this is intended behaviour.

The inconsistent behaviour is that some clients see the image given above, and some see the following:

It seems to be difficult to reproduce the latter, only one person on our team gets it, and it only happens for them in a live game. (Their system info has been labelled ‘inconsistent overshooting behaviour’.)

Workaround

Increasing CanvasSize on that axis to be >= 4 (based on what we can see from the two different screenshots).

Issue Area: Engine
Issue Type: Display
Impact: Moderate
Frequency: Constantly
Date First Experienced: 2022-08-15 00:08:00 (+12:00)
Date Last Experienced: 2022-09-05 15:09:00 (+12:00)

4 Likes

Thanks for the report! We’ll follow up when we have an update for you.

1 Like

Hi, thanks for the bug report. Is there a specific reason for using a SurfaceGui that is smaller than 1px * 1px size? To be clear the size setting under FixedSize means pixel size instead of scale size.

1 Like

It’s been a while so I don’t remember exactly what the purpose of having the smaller sizes was. That may have just been me looking for patterns in the overshooting behavior for the bug report’s sake.

Personally I would prefer the user input to be clamped to >= 1px though so we don’t get weird behavior if we give weird values. But maybe somebody somewhere wants to abuse the behavior…

Either way there’s still an inconsistency when at sizes 1px and 2px (which is certainly how I found the problem in the first place) and I assume the cause of the issue is the same for all the different sizes.