I’ve been working with TextService:GetTextSize() recently to create some UI effects. Upon testing my UI effects on mobile however, I notice some weird size issues occurring.
After some time, I figured out the cause of these size issues were due to the fact TextService:GetTextSize() was returning a Vector2 which contained a decimal offset. The decimal offset is most likely coming from the fact retina screens class 2 pixels (or was it 3?) as 1 pixel in Roblox. When assigning this offset value to a GuiObject’s size property, it was being rounded down, instead of up.
This API shouldn’t be returning a Vector2 which contains a decimal as an offset, as it makes allows for the text to not actually fit. It should be rounded up to the closest whole pixel.
I thought I’d share this here, for hopefully it to be changed, or for anyone else who has who is getting this issue. The best thing right now is to manually round the number up.
4 Likes
Rounding it up improves behavior in some cases but causes problems in others. We’ve been considering changing it so UDim.Offset will be a number instead of an integer, which will prevent the value from being truncated.
Most high DPI (“retina”) devices are 2x, but some are 3x or even 4x. In these cases, rounding up to a whole pixel becomes an increasingly coarsely grained way of measuring things. For example, if you have small text, narrow characters like . (full stop), , (comma), and spaces can end up being only a small single digit number of logical pixels wide. In this case, rounding up will cause these measurements to be offset by something like 30%, which is fairly noticeable.
Another issue is that some devices have non-integer scale factors - 1.25x, 2.5x, and 3.5x seem to be the most common non-integer scale values. On these devices, rounding to an integer will actually make it stop being rounded to native pixels. As a result, on these devices we actually have to re-round integer values into native values.
1 Like
Ah, I never thought of it this way. 30% would be fairly noticeable in the situation you described.
Changing UDim.Offset to a number would be hugely beneficial here then.