With 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!
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.
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?
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?
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.
Unexpected behavior
UIList does not correctly change the position of GUI objects when AutomaticCanvasSize is enabled and when the UIList's AbsoluteContentSize is greater than the ScrollingFrame's CanvasSize.
UIList also does not correctly change the position of GUI objects when AutomaticSize is enabled and when the UIList's AbsoluteContentSize is greater than the ScrollingFrame's Size.
This happens when UIList's HorizontalAlignment is set to center or right or when the VerticalAlignment is set to center or bottom and when the UIList's parent is a ScrollingFrame.
Correctly change the position of GUI objects when AutomaticCanvasSize is enabled and when the UIList's AbsoluteContentSize is greater than the ScrollingFrame's CanvasSize.
Correctly change the position of GUI objects when AutomaticSize is enabled and when the UIList's AbsoluteContentSize is greater than the ScrollingFrame's Size.
I expect UIList to do this when UIList's HorizontalAlignment is set to center or right or when the VerticalAlignment is set to center or bottom and when the UIList's parent is a ScrollingFrame.
Hi @Ryhr , appreciated your detailed description and repro files. If I’m understanding this correctly, the expected behavior is:
AutomaticCanvasSize should size the canvas to the AbsoluteContentSize of the UIListLayout
Center alignment should place the UIListLayout to the center.
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 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.
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…
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 @DaDude_89 and @qwertyexpert appreciate you all providing additional details around the UIStroke issue. We are aware of the issue and are hoping to have a fix for you relatively soon. Appreciate your patience as we resolve these issues
