Problem with high resolution screen display

I have a Windows Surface Pro with a high screen resolution (2736 x 1824).

When I open scide, the help browser is very small and it is impossible to read anything.The same happens when I use GUI windows.

In other programs like Audacity, the GUI (and text) is automatically scaled to the resolution of the screen, but here it is not the case.

It works only if I put down the resolution until (1280 X 800) but in this case, the display of the PDF I use to see my sheet music is very bad.

Are there other solutions ?

IMO it would be fair to log an issue for automatic scaling of the “QWebEngineView” that is driving the help browser. I don’t know Qt well, but there may be some property that should be set internally for high-resolution displays.

As a workaround, the help browser supports standard ctrl-+, ctrl-- and ctrl-0 zoom keys (I’m pretty sure that’s QWebEngine default behavior).

Agreed that it’s not user-friendly for SC to pop up a help browser that is initially unreadable, but until someone can look at that, you do have manual control over the display size.


The ctrl-+ and ctrl-- shortcuts works for the help browser and the scide text editor, but have no effect on Server meter etc… and other GUI objects made in sclang.

Btw, the MuseScore sheet music editor is also made with Qt, and the scores look the same in any resolution.

On the Qt website, there are these informations:

A quick grep reveals that we are not, in fact, using any of the SCALE_FACTOR settings.

This needs to be logged as a bug, then.


Taking another look… I find, “Windows: Qt doesn’t handle high resolution displays well.”

After this issue was opened, SC updated the requirement for the minimum Qt version, leading to the question:

June 9, 2018:
“this might be fixed with #3165 ?”

August 30, 2018:
“… is this still an issue after #3165 or should we close?”

#3165 appears to have been merged into 3.10.

So, the question for this thread is: @bernardgeyer which SC version are you on? Because, if you’re using 3.10, then the answer to the outstanding question on issue 2442 is that 3165 did not fix it.


Two additional comments here -

At the time of that change, I only had a Mac device, so I was only able to do detailed hidpi fixes on that platform. I recall that I never got any positive confirmation of anyone testing hidpi on Windows (even though, frustratingly, half of SC’s downloads are on Windows…), so it’s totally possible that there could still be problems here.

Also - sclang and the IDE only formally support 1x and 2x scaling factors. If you have a device that supports 1.5x scaling on Windows, this is very likely to be the problem (my guess is that 1.5 works in some places, but not everywhere) - I would suggest trying 1x or 2x. If you’re comfortable with building SC, I would be happy to point you to places in the code that might need updates to account for 1.5x, I’m sure other users would be happy for fixes in this area as well.

Finally - how does the sclang UI look? Is it scaled similarly to the IDE, or is it more correct?

Yes, I saw also this issue on Github.
The version of Supercollider I use is 3.10.0

how does the sclang UI look ?
Absolutely not scaled. Totally unusable.

Thanks for confirming that. I’ve added a comment to the issue.


1 Like

This worked for me:

  1. Right click on scide.exe and choose ‘Properties’.
  2. On the ‘Compatibility’ tab click on ‘Change high DPI settings’.
  3. Turn on ‘Override high DPI scaling behavior’.
  4. Try the options on the drop-down menu. I got the best results with ‘System’.
1 Like

For me too it works ! Thank you very much !

Anyway it is important to correct this issue, to avoid that next users with high resolution screens struggle with that.

BTW, is this also an issue on retina Mac computers ? (I don’t have one in the moment)

I’m having problems on Linux with non-integer scale factors… if you could point me to the right places I would be happy to build and test!

P.S. I’m building v. 3.10.3

@scztt I’ve looked at it and found this line:

It looks like removing that round enables fractional scaling for UserViews. As it is now I get widgets scaling properly, while UserViews and Images only scale at integer scale factors. It creates plots like this, at 1.5x on Linux:

While after removing that round():


What do you think? Any reason why that round should stay there?