Screen resolution issues

Dorico
#1

Hi,
I just bought Dorico for my laptop (Daniel said it was designed for laptops!) but the menus/panels are huge and the windows overlap the screen so that about 10% is missing. I’m using a Lenovo Ideapad 710s i7, 8GB, 1920 X 1080.

By default the text/apps scaling in Windows is set at 150% which makes every program, browser, app very workable - except Dorico which is unusable.
Although I can make Dorico work by changing this to 100%, it makes every other program and the desktop unusably tiny!

I had a related problem using the trial version on my workstation, using an ultra-wide screen. The score wasn’t viewable in Print mode. I suspect this is for similar reasons.

I don’t get any of these issues with Sibelius, Cubase, Dreamweaver, Fireworks, etc.
I noticed this has come up before, 6 months ago but still no fix?
options-screen size error.JPG

#2

I’m not sure exactly what we could do to fix this, since you’re asking Windows to make the text 50% bigger than normal, and hence Dorico’s text (and therefore its panels and dialogs etc.) are duly 50% bigger than normal. Have you tried 125% scaling, which is (I think) the default on high-density displays for Windows?

#3

Have you tried this :
Right click on Dorico icon --> properties --> compatibility tab --> check “deactivate display scaling for high resolutions”
Restart Dorico

#4

Hi Guys,
Thanks for those quick responses.

I tried the properties-compatibility tab (thanks Mikhail) and I thought it would work but didn’t. What was interesting though was SOME of the splash loading screen was correct and other bits weren’t.
Halion looks fine but Dorico (and the Hub) are massive.

The recommended (and default) setting on this laptop is 150% but I’ve set it to 125% and fiddled with bits to be able to see anything (I’m not THAT old yet!) and Dorico looks lovely.

I still think there’s something “clunky” in the code though because:

  1. Halion is visually correct
  2. No other program responds in the same way (I hadn’t noticed that scaling was at 150% because it looks correct)
  3. the increase in size seems to be 100% and not 25%

The screenshot attached is the Hub at 125% scaling (looks lovely) but at 150% scaling it was bigger than the screen!
Thanks again.
Looking lovely right now and now I’ll tackle the learning curve! (looking forward to the update too!)
Correct size.JPG

#5

Lenovo Ideapad 710s i7, 8GB, 1920 X 1080

The screen size of 13.3" is certainly a challenge. But when many websites are now able to adapt their size to anything between a 21" desktop display and the 4" display of an older iPhone without discomfort to the user, it seems that other applications need to be designed with the ability to respond to different screen sizes, without the contortions described above. I have a new laptop with the same screen size, but have not yet tried Dorico on it. I will do so in the immediate future and see how convenient the interface is. Even though I have set the display to 150%, text is not always clear, and even worse with Clear Type turned on. My previous laptop was much better in this respect, the only problems being that it runs XP and is twice as heavy as the new one. It has the same width, but the 4:3 aspect ratio is more convenient, and quite adequate for Sibelius. As someone who never watches films on a laptop, I wish that laptops with the 4:3 ratio were still on the market.

David

#6

Dorico is now running on my Asus Zenbook UX310UQK-FC396T with 13" screen.

I have tried the compatibility setting on the properties menu recommended above: it doesnt work here either. I can make the hub and the program windows scale to fit the screen by maximising thm in the normal way. I attach a screen shot (of the whole screen). The screen is 11.6" wide, the note palette is 1.2" wide, leaving only 8.5" x 4.5" for the score. The note sizes are fine for me, but the palette on the left is ridiculously large.

The display is set to 150%, as recommended by the machine, and works fine for everything else – except Photoshop, which has extremely small menus!

Even on my larger screen desktop, I find that Dorico uses a lot of space around the score, which means only a small amount of score can be visible at one time; on the laptop, the amount of visible score is quite inadequate and, for me, makes Dorico only usable on it in an emergency.

David
screenshot-1980.jpg

#7

I have investigated this problem more thoroughly and request a re-opening of the case! For reference, the usable width of my Asus Zenbook laptop window is c. 273 mm. Resolution is 1920x1080.

I discover that, even after the latest Windows 10 update (10.0.15063), unlike other programs, that respond accurately to the screen scaling chosen in the Windows Setting Panel, in Dorico only two for the four listed scalings are actually implemented: 125% gives the same magnification as 100% and 150% the same as 200%. This explains why the change in linear dimensions is 2:1 and not 3:2 when I set 150% – my general setting that works for every other app but one (see below).

The actual widths of the two left hand palettes on my screen are 6/15 mm respectively at 100-125% and 11/30 mm at 150-200%. 30 mm is about 11% of the usable width of the screen. (See attached jpg files) In the hub, the width of the “open selected project” button doubles at the higher magnification to a ridiculously wide 55mm (20% of screen width).

I think I could be happy if either of the two changes proposed below could be made to Dorico, thus releasing valuable working space for display of the actual score:

– The provision of a preference to ignore the Windows global setting (although even at 100%, I find the notes on the second panel unnecessarily large). Adobe Photoshop manages this (to its disadvantage!)

– Implementation of real 125% and 150% scaling (with the caveat above)

Many thanks for your consideration of this proposal.

David
ecm-100.jpg
ecm-150.jpg

#8

+1

#9

Hi Daniel

this is a common issue for apps that aren’t “HiDPI aware”. This is set in the application manifest or by calling a Windows API. It means you need to detect changes to DPI settings (scaling) and respond by scaling your rendering.

In many cases you won’t want to scale e.g. for displaying layout / sheets since these are scalable anyway. Windows will do a lot of scaling for things like icons etc, but the issues tend to crop up with text, esp if you specify fonts by pixels rather than points.

MS has a bunch of documentation on how apps can cope with changes to scaling like this, it’s been part of Windows since Vista, but became a much more prominent issue in Windows 8 and later.

Cheers

Adrien

#10

Dorico is high-DPI aware, and declares all fonts etc. in the appropriate resolution-independent units. The complication is that it uses Qt, which layers its own fun and games on top of the Windows stuff.

#11

A further problem with the 150% (actually 200%) setting on my Zenbook is that the preferences panel, which isnt resizable, is larger than the screen, and thus hard to navigate.

David

#12

Mine is scrollable (if you are talking about the horizontal dimension), and I am using a normal screen resolution. Since panels are appended as needed, that seems to make sense.

#13

The scrolls are off-screen when it opens!

#14

david-p, can you not scroll by dragging two fingers on the touchpad?

#15

Thank you, Leo. An interesting tip that I was unaware of until now! As I have large fingers, I tend to avoid the touchpad, and use the arrow keys or mouse to scroll.

#16

Hi all,

I am trying Dorico and disappointed with this issue that apparently hasn’t been resolved since posted more than a year ago!

Daniel, this is a bug and must be addressed rather that justified by blaming Qt! 150% is a great scaling for my laptop, too, but Dorico responds with a huge, far more than 150%, magnification that just turns it unusable. I am currently working with 125% but suffering with all other application that used to work well with 150%.

Please give us a perspective on this one. As posted earlier, this will become more important as high resolution screens become more common.

Thanks,
Jochen

#17

We do certainly plan to spend some more time working on this issue soon, but I’m afraid as of this moment there’s no news to report.

#18

In the meantime (sorry to drag up an old thread) is there a faster way to switch the scaling (assigning a hotkey or something) to switch the scaling value? Very helpful if you’re on a laptop and find yourself switching resolutions a lot. Thanks for any tips.

#19

Just to report back on this issue, since we have recently revisited it: it transpires that, for the time being, we are unable to make any changes to how Dorico appears on high-DPI Windows systems. The problem is that we are reliant on the Qt framework for our GUI, and although Qt supports high-DPI displays, it rounds the requested scale factor to the nearest integer or whole number. So if you set your display to 125% scaling, that’s a pixel density of 1.25, which gets rounded down to 1, and hence you end up with a visual scale factor that looks too small; if you set your display to 150% scaling, that’s a pixel density of 1.5, which gets rounded up to 2, and hence you end up with a visual scale factor that looks too big.

The reason the Qt developers have chosen this approach appears to be that there are some problems with drawing widgets etc. in the proper Windows style at non-integral pixel densities, and so the current situation is a pragmatic approach to supporting high-density displays. What is unfortunate is that e.g. for a 4K monitor with resolution 3840 x 2160, Windows recommends 150% as the scale factor, so Dorico will look too big on this kind of display by default.

We have raised this issue with the Qt developers again and hope that they will return to this area of the framework soon. As soon as Qt supports these Windows scale factors properly, Dorico will be able to support them too.

#20

Great, thanks for staying on top of this. Do you think it would help if we voted for this bug report (which one is it? There are quite a lot of “high DPI” bug reports in the Qt tracker, at least one of which (https://bugreports.qt.io/browse/QTBUG-55654) mentions this exact “rounding problem” and has been closed as “out of scope” (!))?