Recently made a bug report that covers a similar issue. Maybe this HiDPI thing is related to it? 
(I’m aware the report’s title sounds funny, but can’t edit it because the bug report wizard was used.)
But yeah my UI is entirely screwed up now.
That is the closest I could get to remotely matching what it previously used to look like.
But this is a mockup of what it used to look like.
That’s just a website for tracking the changes Roblox has made to FFlags. If you want to change them locally, you will need to do it manually. If you’re on Linux you can use Grapejuice to do it, otherwise you’ll have to dig around in config files manually since Roblox Studio Mod Manager only works for Studio and macOS simply has no equivalent (because everyone hates macOS for no reason).
Hi all, we are gonna be looking into all the UI alignment issues. Please, if you could provide a repro case, or point us to places where the issues can be reproduced, that would be greatly appreciated! Also, let us know at what DPI scales are causing the problems. Let me know if these issues are critical and are disrupting your experience. We can disable HiDPI on these experiences until the issues are resolved.
For those that want the 3d viewports to render at full resolution, you can try using the DFFlagDisableDPIScale flag, or if you are adventurous the DFFlagVariableDPIScale2 flag. These flags will reduce performance, which is why they are not enabled by default, but we are looking into ways of enabling them when the hardware is sufficiently capable.
I am using the windows 8.1 DPI Scaling, which I heard it fixes the blurring in some of the text- While there may be an alternative, it appears that this scaling factor is making the UI elements really big in my 1080 screen
BrickBattle Reborn has an issue where the killfeed text labels, which are using AutomaticSize, will size themselves such that when the text is actually rendered, it wraps when it shouldn’t.
Please make sure this is manually overrideable.
Can you provide instructions for overriding fast flags without using third-party software? Is there a file somewhere I can modify, safely, without executing untrusted code on my computer?
Can you provide instructions for overriding fast flags without using third-party software? Is there a file somewhere I can modify, safely, without executing untrusted code on my computer?
I wrote a brief guide here:
Is it possible to add such a feature flag that allows the 2D UI layers to render at full resolution (i.e. before this update), as has been done for the game viewport?
It’s all well and good having the 3D viewport more or less as it was before, but it does little to remedy the usability issues when all the UI elements and Humanoid names/chat bubbles are still being scaled up.
Can you show a screenshot, indicate what game you are seeing this on, and at what DPI scale? The DPI scaling should make the text and other UI appear at the same size, but render at a higher resolution. If we enabled HiDPI without scaling, then everything would look much smaller. The scaling is what makes things look the same size, despite the resolution change.
175% Scale (Windows 8.1 DPI Scaling) at 1920x1080 screen
This issue WAS fixed but right now again, this issue makes the UI bigger in every game I join in
This is what it looks like (Game version):
And this is what it SHOULD look like (Studio version):
cc @Stalkalek
What you’re seeing, where the viewport is at full resolution but the GUI elements are scaled correctly, is actually correct and intended behavior. I understand that you’ve gotten used to seeing the GUI elements displayed at your native pixel density, but when DPI scaling is in effect this is actually not correct - the GUI elements should be scaled up by whatever percentage your DPI scaling is set to, which is usually 125% at 1080p and 250% at 4K (although I personally use 200% at 4K).
@nacasagu: I have a checklist for you or your team to ensure that DPI scaling is working correctly and that compatibility with existing games is maintained. Try to hit every point.
GUIs are scaled up according to the device’s scaling factor. Text Stroke and UIStroke width are specified in density-independent pixels, not hardware pixels.
AbsoluteSize and AutomaticSize of TextLabels is calculated correctly. Text does not wrap when the text label’s size is perfectly equal to the bounds of the text.
The viewport is displayed at full native resolution to avoid scaling artifacts. This must be opt-out so that players get a correct, pixel-accurate experience by default, but can disable it if their GPU is not powerful enough.
Camera.ViewportSize still reports in density-independent pixels so that it can be used for sizing GUIs.
Camera:ViewportPointToRay and related functions consume/return density-independent pixels so that they can be used for GUI positioning.
You may want to add a Camera.AbsoluteViewportSize so that games can detect the scaling factor. They should be able to function without needing to care, if everything is properly in density-independent pixels, but being able to know how many physical pixels correspond to a DIP is useful sometimes.
No Lua-accessible functions or properties in the engine deal in native pixels. Everything is in density-independent pixels.
GuiObject.Size, GuiObject.Position, GuiObject.AbsoluteSize, GuiObject.AbsolutePosition, all UDim/UDim2 propertiesTextLabel.TextSize, TextLabel strokeUIStroke.ThicknessCamera functions dealing in pixelsTextService methodsWith DFFlagDisableDPIScale set to true, and DFFlagVariableDPIScale2 set to false, I am still getting a blurry viewport with scaling artifacts.
EDIT: Sorry! I had the path wrong. Mine was %LocalAppData%\Roblox\Versions\version-53d1b11b188e46c2\ClientSettings\ClientSettings.json when it should have been %LocalAppData%\Roblox\Versions\version-53d1b11b188e46c2\ClientSettings\ClientAppSettings.json. Changing the name fixed it. TYSM!
Contents of the file for anyone in future:
{"DFFlagDisableDPIScale":true,"DFFlagVariableDPIScale2":false}
P.S. Do you have a method of enabling the DPI scaling in Roblox Studio? It’s been enabled on macOS for years. Would love to get that back on my new Windows PC.
Well, changing the FFlags doesn’t have an effect for me… (yes I double checked path, filenames and contents)
The best way I can describe the issue for me is all Roblox UI (including the loading screen when you start any game) seems maybe 1.25x bigger than it originally was.
Roblox Studio looks the way it always did, this only seems to affect the Roblox player.
Can this please be fixed soon? I understand some people can manually fix it with FFlags, but I think it’s safe to say the average Roblox user wouldn’t know how to edit FFlags or even know what they are.
See the quote below for explanation.
FFlagClientEnableHiDpi2 is the flag controlling the UI scaling. I would highly recommend you get used to the new UI scaling, though.
“Override high DPI scaling behavior” is supposed to be for getting it to run at your native resolution. Not for making the UI smaller. The UI becoming smaller was an accident. Now the UI is what it should be - native resolution, no pixellation.
Hi @octav20071 - just wanted to follow up with you. Are you still experiencing issues? If so, would you be able to reply back with an RBLX that demonstrates the issue?
Thank you!
Hi @hoontee - are you still seeing issues on mobile? If so, do you have an RBLX file that you can attach that demonstrates the issue?
Thank you.
Hi @DeniedTriangles - is this issue still occurring for you? If so, would you please attach an RBLX file demonstrating the issue for us to investigate?
Thank you!
Nope, it was fixed a few weeks ago. I notice that the resolution is higher today which is neat 
Hi @Ryhr , thank you for providing the repro file. After investigation, we found that in this place, you had the parent frame as a scrollingFrame, the AutomaticCanvasSize is on. In the UIListLayout, the HorizontalAlignment is Center, which makes the scrollingFrame’s “startPoint” the center of the UIList. If you wish to make the scrollingFrame to scroll from the leftmost of the list, you can change the HorizontalAlignment to Left. If that’s not the unexpected behavior you were talking about, I’d assume you were pointing out the end state of scrolling does not stop at the rightmost of the UIList, which means the AutomaticCanvasSize’s calculation didn’t take the Alignment of the UIListLayout into account, which may require some further investigation. Please verify with the HorizontalAlignment change mentioned above to see if that fix your issue. Or could you please provide with more detailed unexpected behavior in this case and the expected behavior? Thank you!
This is a reply to you that provides you with the unexpected behavior that has more details and the expected behavior.
Reproduction file (AutomaticCanvasSize set to x, HorizontalAlignment set to Center).rbxl (38.7 KB)
Reproduction file (AutomaticCanvasSize set to x, HorizontalAlignment set to Right).rbxl (38.7 KB)
Reproduction file (AutomaticCanvasSize set to y, VerticalAlignment set to Center).rbxl (38.7 KB)
Reproduction file (AutomaticCanvasSize set to y, VerticalAlignment set to Bottom).rbxl (38.7 KB)
Reproduction file (AutomaticSize set to x, HorizontalAlignment set to Center).rbxl (38.7 KB)
Reproduction file (AutomaticSize set to x, HorizontalAlignment set to Right).rbxl (38.7 KB)
Reproduction file (AutomaticSize set to y, VerticalAlignment set to Center).rbxl (38.7 KB)
Reproduction file (AutomaticSize set to y, VerticalAlignment set to Bottom).rbxl (38.7 KB)
Hi @Ryhr , appreciated your detailed description and repro files. If I’m understanding this correctly, the expected behavior is:
Since our design of AutomaticSize is to follow the behavior when there is no AutomaticSize set but set the size correctly, we can look at the problem when AutomaticSize is off. If you have a duplicate of this UI structure and turn all the AutomaticSize off, and set the canvas size to the AbsoluteContentSize of the UIListLayout manually, you can see that setting the HorizontalAlignment to Center or Left or Right doesn’t trigger any change. Because the starting status of the canvas position is 0. And the UIListLayout should fill the canvas since they are the same size.
If you want the starting status of the ScrollingFrame is to scroll from the center, you should probably consider using Left Alignment and changing the CanvasPosition correctly to the center, or using UIPageLayout. The AutomaticCanvasSize can only calculate the canvas size, but not change any position.
But there is indeed some issue with the AutomaticCanvasSize here that the UIListLayout is positioned incorrectly. We will keep investigating this problem.
Please feel free to let us know if the expected behavior understood above is incorrect.
