search

GabeRundlett / desktop-shadertoy

A fully featured desktop client for shadertoy
Apache License 2.0
72 stars 6 forks source link

Hard to read descriptions / Windows DPI scaling / GUI size #8

Open teadrinker opened 3 months ago

teadrinker commented 3 months ago

I have a high DPI screen (using the 200% setting in Windows 10) And some of the text is quite hard to read.

However this is not really an issue for me as I don't really need to read those, kind of nice to get more screen estate actually... But if more UI is added, this should probably be fixed at some point...

(windows explorer as reference of typical text size)

desktop-shadertoy_24-08-01__13-53-32

GabeRundlett commented 3 months ago

Yeah you're right. I think it matches the default zoom on the website but I might be wrong. A bit of a hidden feature is that you should be able to press Ctrl + to zoom in (and minus for out)

teadrinker commented 3 months ago

Oh cool, general DPI scaling is already supported then! works well!

I guess then there is something wrong with the init only, as it seems to init to half the size here (using 200% windows scaling)

GabeRundlett commented 3 months ago

Ah I didn't understand before but I do now. Yes I don't respect the current OS DPI scale. I definitely should, and that's why it looks so small for you. I will fix that.

RedNicStone commented 3 months ago

GLFW doen't natively support any HiDPI functions, this would have to be done using system apis. On startup the application would need to query the system set scale for UI elements (referred to as 'window scale').

On linux+x11 there are a few ways this can be done, but the 'correct' way to do this is to query the xrm database for the value Xft.dpi which should contain the window dpi value.

On linux+wayland fractional scaling is still being developed, and I would hold off on implementing it until this discussion has settled.

On windows there is a winapi function which can be used to query the dpi for the current monitor.

What makes this a little more difficult is handling the scenario when the dpi was changed or the window was moved to a different screen. On windows you can subscribe to a message (WM_DPICHANGED) that gets called when the dpi for the window was changed. On x11 this does not exist and its tradition for apps to only read the dpi on startup (sad).

@GabeRundlett I'm happy to implement the changes required for this, message me in #gabe-general-vox about it.