[LH4567] RC6 high DPI version not working?

User avatar
jje
Posts: 339
Joined: Sun Jul 06, 2014 5:57 pm
Platform: Windows
Location: Sussex, UK

Wed May 27, 2020 7:31 am Post

Hello,

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:
Screenshot.jpg
Screenshot.jpg (831.27 KiB) Viewed 668 times


-- 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:
Screenshot2.jpg
Screenshot2.jpg (758.01 KiB) Viewed 668 times


-- no change at all. So, back to the regular RC6 for now...

User avatar
jje
Posts: 339
Joined: Sun Jul 06, 2014 5:57 pm
Platform: Windows
Location: Sussex, UK

Wed May 27, 2020 7:45 am Post

And, just to confirm, installing the plain RC6 over the High DPI version fixed the problem.

ad
adrm
Posts: 123
Joined: Sun Dec 02, 2018 11:58 am
Platform: Windows

Wed May 27, 2020 8:08 am Post

I opened a couple of old projects on my high-DPI ultrabook, and so far everything looks normal.

User avatar
Jestar
Posts: 299
Joined: Sun Feb 19, 2017 6:51 pm
Platform: Mac + Windows

Wed May 27, 2020 8:53 am Post

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.
Win 10 Ent. 64-Bit 2004
Intel Core i7-2600 @ 3,4 GHz (Quadcore) 32 GB RAM
Samsung SSD 860 EVO 500GB
NVIDIA Quadro K600
Scrivener Version: Version: 1.9.16.0 - 14 Nov 2019 & Version: 2.9.9.8 Beta (984254) 64-bit - 12 Jul 2020

User avatar
MimeticMouton
Posts: 8826
Joined: Wed May 05, 2010 5:39 am
Platform: Mac + Windows
Location: city of rain
Contact:

Wed May 27, 2020 9:15 am Post

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).

Jestar wrote: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.

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. :)

Jestar wrote: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.

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?
Jennifer Hughes
(MM for short)

fp
fpshed2
Posts: 65
Joined: Tue May 15, 2018 10:06 am
Platform: Windows

Wed May 27, 2020 9:24 am Post

Where in release Notes did you find a download link to this HiDPI version, please?
Regards,
Bill Antonacchio

User avatar
jje
Posts: 339
Joined: Sun Jul 06, 2014 5:57 pm
Platform: Windows
Location: Sussex, UK

Wed May 27, 2020 10:06 am Post

fpshed2 wrote:Where in release Notes did you find a download link to this HiDPI version, please?


Just scroll down past the list of fixed bugs; the link is after the note about the two remaining known issues.

JR
JRanck
Posts: 8
Joined: Sat Dec 11, 2010 6:57 am
Platform: Windows

Wed May 27, 2020 5:35 pm Post

MimeticMouton wrote: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).


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.
Attachments
Capture.JPG
Capture.JPG (108.29 KiB) Viewed 531 times

ch
chrisdr2
Posts: 31
Joined: Wed Oct 16, 2019 9:09 am
Platform: Windows

Wed May 27, 2020 6:25 pm Post

I have a Surface Pro and want to tryout the DPI version. Is it intended to be installed separately for testing or over the top of RC6?

User avatar
Jestar
Posts: 299
Joined: Sun Feb 19, 2017 6:51 pm
Platform: Mac + Windows

Wed May 27, 2020 9:25 pm Post

MimeticMouton wrote: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).

I will try this out once I get back home for my Surface Pro.

MimeticMouton wrote:
Jestar wrote: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.

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.

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.

MimeticMouton wrote: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. :)

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.

MimeticMouton wrote:
Jestar wrote: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.

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?

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.
Win 10 Ent. 64-Bit 2004
Intel Core i7-2600 @ 3,4 GHz (Quadcore) 32 GB RAM
Samsung SSD 860 EVO 500GB
NVIDIA Quadro K600
Scrivener Version: Version: 1.9.16.0 - 14 Nov 2019 & Version: 2.9.9.8 Beta (984254) 64-bit - 12 Jul 2020

User avatar
MimeticMouton
Posts: 8826
Joined: Wed May 05, 2010 5:39 am
Platform: Mac + Windows
Location: city of rain
Contact:

Thu May 28, 2020 7:12 am Post

JRanck wrote: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.

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.

Jestar wrote:
MimeticMouton wrote:Is this different from what you get with the non-High DPI build?

The non-highDPI version didn't seem to suffer from this before, however, I will need to install it to check it now.

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.

CHRISDR2 wrote:I have a Surface Pro and want to tryout the DPI version. Is it intended to be installed separately for testing or over the top of RC6?

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.
Jennifer Hughes
(MM for short)

ch
chrisdr2
Posts: 31
Joined: Wed Oct 16, 2019 9:09 am
Platform: Windows

Thu May 28, 2020 2:01 pm Post

MimeticMouton wrote: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, I'll uninstall and try the High DPI build. If I keep it installed, will it automatically pick up the next update?

JR
JRanck
Posts: 8
Joined: Sat Dec 11, 2010 6:57 am
Platform: Windows

Thu May 28, 2020 6:47 pm Post

MimeticMouton wrote: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.


Here's my system/monitor specs:

SurfacePro 7
LG 38WK95C widescreen monitor
From the win10 display settings I'm showing 100% scaling with the "let windows try to fix apps so they're not blurry" option checked in the advanced scaling settings.
From the log file:
Info: devicePixelRatio: 1
Info: qt_defaultDpi: 96
Info: qt_defaultDpiX: 96
Info: qt_defaultDpiY: 96
Info: Primary Screen: ""
Info: Primary Screen devicePixelRatio: 1
Info: Primary Screen logicalDotsPerInch: 96
Info: Primary Screen physicalDotsPerInch: 111
Info: Screen 1 ""
Info: Screen devicePixelRatio: 1
Info: Screen logicalDotsPerInch: 96
Info: Screen physicalDotsPerInch: 111
Info: Runtime Location: "C:\\Program Files\\Scrivener"
Info: Installed Location: "C:\\Program Files\\Scrivener"
Info: Loading Icon Manager icons.

Let me know if you want the whole log file. There are a lot of lines about "known incorrect sRGB profile" warnings.

User avatar
MimeticMouton
Posts: 8826
Joined: Wed May 05, 2010 5:39 am
Platform: Mac + Windows
Location: city of rain
Contact:

Fri May 29, 2020 6:38 am Post

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.
Jennifer Hughes
(MM for short)

fa
fadedwave
Posts: 73
Joined: Sun Nov 14, 2010 5:13 pm
Platform: Windows

Sat May 30, 2020 4:24 pm Post

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.
Western Redemption in Dystopian America
Read The Wanderer and the New West by Adam Bender