I was interested to see (in the latest release notes) that there’s a new “HiDPI version of RC6” we can try. There’s no explanation of how this differs from the regular beta, but as I have a 4K monitor, I thought I’d give it a try.
Just installed and started and this is what I see:
– masses of weird new space where there shouldn’t be any. I wondered if I’d made some changes to the default appearance in an earlier beta that were causing this problem, so I reset the appearance to default (under “Options”), restarted Scrivener and:
Using the High DPI 64-bit version on my Surface Pro. Resolution set at 2736 x 1824 with 200% scaling - everything looks normal. Using Scaling factors of 100, 125, and 150 and I get the same extra spacing noted above. At 175% things seem more towards normal. Anything over 200% makes a mess of things by being too big and stuff lands outside the screen with no way to scroll to get to the right side of the maximized window. Dropped back to 200% (Windows recommended value). Only issue noted outside of the scaling issue noted is with using the touch feature to move the scroll area - was very sluggish and slow, and selected document text while trying to move up/down within the document. I typically use an external mouse/keyboard setup when I can as the Surface Pro keyboard cover is smaller than I care for but the trackpad works fine.
Thanks, the issue with the vertical spacing around the format bar has been filed. This is related to the height of the window, so is more pronounced the taller it can get on your screen. Opening the inspector will fix it for the time being (or of course you can switch to the other build).
Is this different from what you get with the non-HiDPI build? The High-DPI version should improve the graphics scaling (compared to the other version, which uses an older framework that does not scale the graphics correctly, changing the ratio of text size to the rest of the interface at different zoom levels), but at a certain point, the scale factor is just going to be too high for the minimum window widths.
As a general note, when running into a situation with the window off the edge of the screen, Alt+Space , M select’s the window’s Move command, allowing you to then use the arrow keys to shift it on the screen until you can see the edge. Of course that won’t help much for windows that can’t be resized.
Thanks for the note. I’m assuming this is a measurable difference from the non-HiDPI build using the same project.document and Windows display scaling?
So opening the inspector did not fix the issue for me. Attached is what I’m seeing. Also note the large rendering of “No Label” and “No Status” on the bottom bar.
Also the opening splash dialog that says when RC6 will expire is rendered very large.
I will try this out once I get back home for my Surface Pro.
The non-highDPI version didn’t seem to suffer from this before, however, I will need to install it to check it now. The Surface Pro uses really weird resolutions and scaling factors, which makes many programs wonky if they are not built by Microsoft. Case in point is VMWare Horizon which my work is having all sorts of issues in setting screen size of vm’s to work with the Surface Pro. No issues with other laptops or desktops, just the Surfaces.
I wasn’t able to do the move trick because I was way past the size of the tiny screen (perhaps if I had continued further?). Either way, it was way too big to be comfortable for viewing past the recommended scaling factor of 200%. Was able to see the first couple of menu items of the Scrivener main menu and the toolbars. After that, it would have been moving the window around to see the rest.
I’ll have to check to be certain, but I’ve never had really good experiences with the Surface Pro’s touch screen. It had been mentioned before in these forums and I wanted to see if the highDPI version would make a difference. It did not. I’ll try it with the non-highDPI version and maybe try it out with the stylus. It could be that my fingers are just too big for fine control of the touch screen.
Hm, good to know, The enlarging of the format bar is obviously a bug; I had just found that the inspector being open popped it back into place and hoped it might help anyone experimenting with this.
The large text size in the inspector footer is also odd; that looks like the sort of scaling that comes with the non-HiDPI version. What is the display scale on your machine? It would be helpful also to see the monitor specs that Qt is reporting. If you go into Scrivener’s installation folder, you can right-click on the ScrivenerLog file there and choose “Run as administrator” and confirm, then quit Scrivener once it’s open. If you refresh the file browser, there should now be a “logs” folder within the Scrivener installation folder, and you can zip and attach the text file within that, or open it and copy and paste the “Info” lines partway down, beginning with “Info: devicePixelRatio” through the “Info: Screen physicalDotsPerInch” line.
I don’t know if this appears differently on the Surface Pro, but my own experience with the non-HiDPI version is that the graphics would wound round to the nearest 100 in the display scale, while the text seemed to follow the Windows scaling more accurately. Thus you could do something like a 225% display scale and get the window, buttons, and other interface elements scaled to about 200% while the UI text was scaled up higher to the 225% setting, which would make the text look a little crowded or thick in places (like the Status and Label text in JRanck’s screenshot). With the High DPI build, text and graphics seem to be keeping in line, so in this case it would probably overall look bigger, since the graphics are scaling correctly now to 225% rather than only 200%. So maybe that’s part of the difference you’re seeing.
Best to use one or the other, as they wouldn’t be fully isolated if you had them installed side by side and it might get confusing. But you can easily test one and then replace it with the other, as you choose. Both have the same beta expiry date and same features; the difference is just in the DPI-aware update to the framework in the one.
Just a general FYI, we’ve also noted (for the High DPI build) a UI issue with the editor footer stretching up when viewing a webpage in the editor.
Thanks, JRnack. I’ve added your display info to the ticket on this; shouldn’t need any of the other info from the log, but I’ll let you know (or Tiho will) if it turns out some other details fro that would be helpful.
chrisdr2, the high-DPI build will automatically check for updates, but it will download the regular version once RC7 is out; for the time being, you’ll need to manually download and install the high-DPI version if you want that again.
Dumb question, but at what resolution would I see benefits from using the high DPI version? Just want to know if it’s worth me trying it or if I wouldn’t see a difference.
It has less to do with resolution than it does how dense the pixels in your display are – hence why it’s called “dots per inch.”
Wikipedia has a good overview of DPI and how it relates to various categories; I of course cannot state categorically whether their definition of HiDPI matches what Wikipedia says.
