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.
Hi, itâs me again, Iâm still having issues with outlines of various objectsâŚ
The button has a UIStroke with Bevel and a thickness of 2. This image is taken when I had the FFlagClientEnableHiDpi2 disabled. (a bit hard to tell with the screenshot but the right/bottom strokes are thinner than the top/left)
This is a screenshot taken when I had the FFlag enabled. Now the stroke is even and looks normal:
The issue is, with the FFlag enabled all my Roblox UI seems significantly smaller, and as qwertyexpert says having it disabled is the right way. Iâve messed around with other FFlags but FFlagClientEnableHiDpi2 is the only one that affects this for me.
This is incorrect - the UI elements should be scaled to your screen size, however, the stroke shouldnât be rounding to the nearest pixel (I also have this issue where thereâs a gap between the background color and the stroke). I believe this is due to the stroke not supporting subpixel precision for size or thickness.
This should be fixed by a recent Roblox update, could you re-test this and verify if itâs still an issue?
This issue still happens, unfortunately. Iâm assuming its because itâs trying to scale half or quarter a pixel, and its rounding to the nearest pixels instead.
I understand why they would round the pixel instead of making a blurry line, but I think Roblox should opt for consistent stroke thickness rather than display accuracy.
This issue mentions âDPIâ. I assume, that your screen also gets scaled. Now, thereâs a fix that you can do so that you can have your screen back to normal. Having to modify "Override high DPI scaling behavior" just so Studio doesn't appear blurry and poorly scaled - #26 by ittrgrey
Now, I do agree, that it would be cool if there could be some sort of FFlag ingame, in Studio, or something in Studio that makes an UI element unaffected from the DPI Scale.
Now, the thing is, the entire Roblox UI is being affected by it⌠soâŚ
And this manual fix, with creating that .json file has to be done everytime Roblox updatesâŚ
See my post above:
Disabling the DPI scaling behavior is incorrect. Itâs not ânormalâ.
Yes, thereâs a bug with UIStroke and a couple other things, but Roblox is working them out. Make bug reports. Please STOP spreading misinformation about this change.
If itâs a change in behaviour that we havenât been forewarned about, or given reasoning as to why itâs happened, then yes, it counts as a bug. When itâs something this significant that hasnât changed since the early days of Roblox, it is arguably a regression that is being made.
Hi @Mauio64 (and others in this thread!) - the issue affecting proximity promptsâ default UI should now be resolved. Thanks for reporting this!
