Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

UI is not high-DPI aware #2

Closed
baldurk opened this issue Feb 27, 2014 · 14 comments
Closed

UI is not high-DPI aware #2

baldurk opened this issue Feb 27, 2014 · 14 comments
Labels
Feature An improvement or feature Unresolved Waiting for a fix or implementation

Comments

@baldurk
Copy link
Owner

baldurk commented Feb 27, 2014

As description :).

http://www.crydev.net/viewtopic.php?f=379&t=121165

@Anteru
Copy link
Contributor

Anteru commented Mar 19, 2015

It's ok with Windows 8.1, just blurry -- and would be great if it did proper HiDPI cause I could capture at 1920x1080 and see the previews at close to 1:1 :) -- should be easy for the Qt based UI, not sure how easy it is for WinForms.

@baldurk
Copy link
Owner Author

baldurk commented Mar 19, 2015

Good to know that it's semi usable, I think at one point the text was getting clipped and things, but I guess 8.1 is just rasterising it at a lower-res then doing a naive upscale. I did some initial research a while ago and I think I need to set up whether it scales based on font-size or by points or something else, then make sure all of the layouts will handle resizing correctly (no use of hardcoded pixel dimensions etc etc). Hopefully not too hard, just need to go around fixing all the bugs :).

The Qt UI will probably only be for linux/OS X. It will work on windows since I'll develop it there, but the windows UI will remain winforms for the foreseeable future.

@Anteru
Copy link
Contributor

Anteru commented Mar 19, 2015

Yes, Windows 8.1 simply upscales with blur, which is ok'ish. Qt would do it right away for you, as would WPF, but for WinForms I have no idea how to do it properly. IIRC, future .NET versions (4.6?) will contain fixes for .NET controls and HiDPI.

@baldurk
Copy link
Owner Author

baldurk commented Mar 19, 2015

Yeh WPF would handle it much easier, but I tried WPF a while ago earlier in development to see if I should switch and it was... unpleasant to say the least!

I believe it is totally doable even on current .NET versions, it's just not something I've prioritised looking at.

@sebbbi
Copy link

sebbbi commented Nov 6, 2016

Got a new 4K display last week (1.5 scaling factor, matches 2560x1440 in size). RenderDoc looks blurred. Especially the fonts at quite bad. Hopefully this bug increases in priority. 4K console launches soon (PS4 Pro) -> developers are now upgrading to 4K monitors.

@baldurk
Copy link
Owner Author

baldurk commented Nov 6, 2016

Well a couple of things have changed since the last comments - I found that trying to implement proper high DPI support in the existing .NET UI would be kind of a nightmare and isn't a worthwhile time investment, but also I realised that supporting two UIs (.NET and Qt) wasn't going to be feasible and I found ways to get around my concerns with Qt as a replacement, so eventually the Qt UI will be the main UI on all platforms.

With Qt, hopefully DPI handling should either come for free, or it's an upstream bug to be fixed in a version of Qt, but until then this bug honestly won't see any progress. When it was originally opened back in 2014, this was before windows would just render the window at lower resolution and scale up. That would be enough with no fixes even needed really, except for the texture previews which you want to be 1:1.

@sebbbi
Copy link

sebbbi commented Nov 7, 2016

Thanks! I will wait for the Qt UI.

@baldurk baldurk added Feature An improvement or feature and removed Bug A crash, misbehaviour, or other problem labels May 9, 2017
@hrydgard
Copy link

Something that could probably be fixed quite easily, though, without changing UI framework, would be the on-screen overlay when running - it's really, really tiny on 4K displays.

@baldurk
Copy link
Owner Author

baldurk commented May 31, 2017

The UI framework is actually almost changed now, but some kind of scaling on the on-screen overlay would be nice indeed and will still be needed. I'm not sure how easily the DPI can be queried from inside the API hooks though.

This is kind of difficult for me to test since I don't have any high DPI screens. If anyone wants to take a crack at this, there's a scale factor on each of the APIs in the text rendering - search for TextSize which is currently double the actual texel dimension of the characters, so it can be multiplied up further for higher DPI screens.

@hrydgard
Copy link

hrydgard commented May 31, 2017

Hm, yeah, whether to scale depends on if the target application is DPI-aware or not ... if the OS is scaling the target, it would be wrong to enlarge the overlay UI.

Anyway, for some kinds of testing, you can just blow up your Windows desktop scale to say 225% to simulate it - gonna be a bit cramped though :)

@baldurk
Copy link
Owner Author

baldurk commented May 31, 2017

Right, you need to know what the DPI awareness of the application is, the DPI of the monitor that the window is being displayed on (which might be different to the primary monitor), all factoring in.

Technically you can change the scaling alone like that, but I really don't want to count on that behaviour being representative :).

@serhii-rieznik
Copy link

+1 to this issue. Even on 125% scale (15" full hd laptop screen) it looks blurry.
2017-06-04

@bioglaze
Copy link
Contributor

bioglaze commented Jun 9, 2017

In addition to being blurry, hovering tooltips are misplaced (tested on a 4k display, Win10, 150% scaling). Tested with RenderDoc v0.34:

hover

@baldurk
Copy link
Owner Author

baldurk commented Mar 6, 2018

v1.0 is now officially out, replacing the .NET UI program with a Qt-based UI that supports high DPI screens natively. Any further DPI issues with the new UI should be reported separately.

Rest in peace to the oldest bug on the repository!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Feature An improvement or feature Unresolved Waiting for a fix or implementation
Projects
None yet
Development

No branches or pull requests

6 participants