-
Notifications
You must be signed in to change notification settings - Fork 404
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
Windows HiDPI support #1547
Comments
One solution that I have done elsewhere in an unrelated project is initially scale and store all vector to bitmap conversions to relatively large internal size, thus ignoring the initial dpi issue entirely. Then always scale down. This works well but with slight increase in memory footprint. |
Yeah in 17 we did exactly that with this implementation surge/src/windows/DisplayInfoWin.cpp Line 34 in 8369a6f
|
So I think the correct implementation here would 1: go frame -> hwnd rather than simply "return 2" I think a super-complete implementation would also hop into vstgui.surge/vstgui/lib/platform/windows and modify win32frame so that the WM_DPICHANGED message invalidated you but that's probably more trouble than its worth. So for now I think just a readonly access. Take a look at src/windows/DisplayInfoMac.cpp for an example! |
JUCE, our savior, deliver us from the pain that is VSTGUI! |
Yeah you should just try xt. The SVGs render perfectly in mac retina with none of my code for vstgui being used |
Oh so it's using 1.0 backing store on non-HiDPI in XT now? I don't see anything changed there in |
The juce code path never calls backing store resolution |
Oh! |
So wait, is this one basically implemented and could be closed simply by virtue of having XT building fine across all platforms (even if it's not completed yet)? |
Well does XT do the right thing on Windows HDPI? |
It seems to be using backing store 1.0 over here on non-HiDPI, but I suppose I should check on my Surface and report back 🙂 |
The answer is: yes, yes it does! So closing it ahead of schedule. 😁 |
Right now windows in display info always return a backing store density of 1. This means we render to a 96dpi pixel in cscalabalebitmap and some zooms are blurry
We could alternately support the hdpi api and set that scale factor then test in all the hosts and display configurations but I don’t know those apis don’t have those displays and don’t run those hosts! So adding a placeholder issue
The text was updated successfully, but these errors were encountered: