Problem with high resolution screen display

bernardgeyer · February 22, 2019, 12:27pm

Hello,
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 ?

jamshark70 · February 23, 2019, 2:09am

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.

hjh

bernardgeyer · February 24, 2019, 9:04am

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:
https://doc.qt.io/qt-5/highdpi.html

jamshark70 · February 25, 2019, 1:03am

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.

hjh

jamshark70 · February 26, 2019, 7:03am

Taking another look… I find https://github.com/supercollider/supercollider/issues/2442, “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.

hjh

scztt · February 26, 2019, 8:08am

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?

bernardgeyer · February 26, 2019, 4:40pm

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.

jamshark70 · February 27, 2019, 12:54am

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

hjh

trocado · March 1, 2019, 10:18pm

This worked for me:

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

bernardgeyer · March 3, 2019, 11:52am

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)

elgiano · December 2, 2019, 12:27pm

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

elgiano · March 25, 2020, 12:13pm

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

github.com

supercollider/supercollider/blob/8f87c09a8194e379cd0dd29b5d3905e55ff10bed/QtCollider/widgets/QcCanvas.cpp#L157


    QPainter painter(this);
    QPalette plt(palette());


    if (_bkg.isValid())
        painter.fillRect(e->rect(), _bkg);


    if (_bkg_image.isValid())
        _bkg_image.paint(&painter, rect());


    if (_paint) {
        qreal pixelRatio = round(backingStore()->window()->devicePixelRatio());
        auto sourceRect = e->rect().intersected(QRect(0, 0, size().width(), size().height()));
        sourceRect = QRect(sourceRect.topLeft() * pixelRatio, sourceRect.size() * pixelRatio);
        painter.drawPixmap(e->rect(), _pixmap, sourceRect);
    }
}


void QcCanvas::timerEvent(QTimerEvent* e) {
    if (e->timerId() == _timerId) {
        ++_frameCount;
        ++_meterFrames;

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?