UI Scale Issue with New Renderer

[Hexafish]

I have a 2560x1440 screen. However, I usually don't like my applications such as Firefox as well as the native windows apps being tiny, so I scale my applications to 150% in Windows.

Unfortunately, Path of Building respects this as well, and its the one application I prefer at 100% so I can utilize more of the screen. Previously with the old rendering engine, I was able to fix this by right clicking the app, selecting Properties -> Compatibility -> Change high DPI settings -> Checking Override high DPI scaling behavior -> Application, and PoB would render as though the application scale was 100%.

With this new engine, that doesn't work and I need to change my windows scale to 100% every time which is not convenient as it messes with Firefox and also makes interacting with anything weird as my mouse DPI is not affected by resolution scales, so the mouse moves slower.

[zao]

This is a fun niche use case that I didn't consider with the new runtime.

Context

In the original runtime, the program didn't know anything about DPI and as such, Windows defaulted to scaling it up from the outside. As you noted you could lie to Windows and tell it that the program could handle DPI itself and thus rendered naively at 100% scale.

In the new runtime, the program has a DPI-aware window out of the box and as such, altering the choice in Windows between System and Application has no effect, as System understands the program's declaration and transfers control to the program.

In the program, as we're now responsible for scaling the graphics and input ourselves we set up a low resolution render target and scale that up with the DPI scaling factor we obtain from Windows. The funny thing is that if we were to do nothing, we'd end up rendering at 100% scale like you would expect, but unlike what most user that intentionally configure a scale in Windows would expect.

Workaround

I don't have any immediate long-term solution for you unfortunately. This stretching-on-our-own functionality was to keep usability until a future date when we've made the UI more scalable in itself and can allow it to draw at full resolution with the individual controls at scaled dimensions.

The best I can offer you now is a hack which will be undone whenever there's an PoB update as it modifies the Lua code.
You would be replacing RenderInit() in src/Launch.lua with RenderInit("DPI_AWARE"), which tricks the runtime into thinking that the Lua code can draw things at scale, which it can't and as such will draw at 100%.

PathOfBuilding/src/Launch.lua

Lines 64 to 68 in 4f7ffcb

	installedFile:close()
	end
	RenderInit()
	ConPrintf("Loading main script...")
	local errMsg

If you opt to do that, don't forget to actually update PoB occasionally and reapply the fix afterwards.

It's possible that we might be able to do some other sort of hidden knob to steer the scaling factor for power users, but I haven't thought that through yet.

[Hexafish]

That seems like a surprisingly simple fix for something that I assumed would be slightly more complicated to fix given the explanation. Can confirm it works as intended though.

[istarogh]

Thanks for the workaround instructions. I, uh, tried making that edit to the Launch.lua file in my PoB directory (%AppData%/Path of Building Community), but that prevented PoB from loading at all, even after I changed it back, until I redownloaded Launch.lua from GitHub. I'm guessing you meant not "just change the local file" but rather something involving downloading all the code, making the change, and figuring out how to do the build myself?

In any case, I wanted to add my voice, a "+1" so to speak, to the effect that maybe this isn't quite that niche an issue. I run Windows 10 at a custom scaling factor of 125% to ease eye strain. Which, if I correctly recall the process I went through many years ago and why I did so, is different from a non-custom scaling factor of 125% in that it prevents legacy programs from exhibiting that characteristic "DPI problem" fuzzy text. With the exception, now, of PoB. That is, before today it looked like this:

and now it looks like this:

(Straight lines, for example, used to be crisp single-pixel lines, and now are accompanied by ghosting.)

[chx]

To add a different voice, PoB was very near unusable before for me at 200% scaling on a 55" HDTV so I used the compatibility fix but that made it almost impossible to read , it was so tiny. I can live with a little blurriness if that's the price for otherwise usable PoB.

[Terroosh]

I don't know if niche would be correct here. Myself and all my friends play using various resolutions all with scaling enabled. In fact many gaming laptops come with some sort of scaling % enabled by default. In any case, all of us have a hard time using PoB because of how tiny the text size is so hopefully at some point PoB will be able to render at above 100% without the blurry text/smearing issue.

[zao]

Varying display densities and preferences are indeed way more common these days, I didn't intend to diminish the impact for any group.

I've wanted to do crisper UI for a long while as I daily drive dense displays at 150%-200%.
On custom vs. non-custom scale factor, I don't know what Windows does differently there.

There's some existing body of research out there on content-aware scaling in emulators and even Windows itself, but researching and implementing something like that also takes time.

[Silverun]

After 2.41 update my PoB looked like 800x600 on fullHD monitor. I think I have 125 scaling in Windows 10. This workaround helped.

[Sheodar]

Bump? Can we do a bump?

[istarogh]

As of 2.42.0 (March 30th) it's once again possible to opt-in to crisp 100% scaling, ignoring your setting for the rest of Windows, using the method mentioned in the OP.

[missingdays]

I have a 4k monitor and the scaling setup in the OS settings are not respected. The app is rendered with a tiny UI

Workaround with RenderInit("DPI_AWARE") also didn't help

[zao]

@missingdays As this screenshot seems to be from some Linux distribution, I'm not certain which flavour of PoB you're running.
Is it the real Windows version we ship running under Wine or a third party package like the one from Arch AUR or the Flatpak packages?

For our real version, we declare at startup that we are DPI-aware and thus want to handle scaling ourselves.
We query the DPI scaling value from the OS and draw to a proportionally lower resolution render target which is upscaled to the desired scale for presentation.

RenderInit("DPI_AWARE") as a workaround inhibits this mechanism in our runtime, drawing the UI at 1:1 to underlying pixels. The real purpose of this flag is to allow the Lua-side UI to query the scale factor, pick font sizes and place/size UI elements accordingly to get a crisp high-resolution UI. It happens that it's also a workaround for people who have functioning DPI scaling in the OS but wish to keep PoB at 1:1.

You might have to dig into your environment and Wine yourself and see if you can get it to forward or honor DPI scaling, we have extremely limited bandwidth for addressing interactions like this when we use the proper Windows API functions already.

[missingdays]

@zao I installed Path of Building from Lutris, here https://lutris.net/games/path-of-building/

we have extremely limited bandwidth for addressing interactions like this

Of course, I understand how low of a priority such issues must be. I'm just adding a datapoint to the issue that seemed relevant

[missingdays]

What helped me was going to Wine config in Lutris

and in graphics changing the screen resolution value

After that, Path of Building is rendered in a more readable resolution. It looks a bit blocky, but much more usable

[Silverun]

Hey, I have ran troubleshooter for the app and the issue has been fixed!
I have 125 % scaling in system. PoB was blurry, OP fix helped but you needed to apply it every time after update.

Go to PoB.exe properties - Compatability - Change high DPS settings - Override high DPI setting - Application