Sublime Forum

**wbond** · September 15, 2016, 6:32pm

Yes, there are are two scaling issues in 3121/3122 affecting HiDPI on Windows/Linux:

hit targets for links are offset
scrolling can causes lines of content to be occluded from view before they should be

Fixes for these will be in the next build.

**facelessuser** · September 15, 2016, 6:37pm

Thanks for the confirmation. I’ll wait for the next release.

**prmaple** · September 21, 2016, 11:22am

Hi, with ST3123 the links are now clickable at where they appear, and no longer appear as ~~“stroke through”~~.

However, the color squares are still remarkably large (as before) no matter what value I set in “mdpopups.font_scale”

**facelessuser** · September 21, 2016, 1:51pm

I will give it a try. I haven’t upgraded yet due to other stability issues in previous versions of Sublime dev. But again, it may still be a Sublime issue, but I’ll check.

**wbond** · September 21, 2016, 1:55pm

Just an FYI, build 3123 is the last dev build before we release 3124 as a beta – baring any reports of major issues.

**facelessuser** · September 21, 2016, 2:30pm

@wbond, Thanks, I will try and get any bug reports in soon if discovered. I have meetings all day these next two days, so I may not get to test any of this stuff out until Friday :(.

**jcberquist** · September 21, 2016, 2:33pm

I see the same, and it seems to be related to what value I set in the Windows 10 display settings scaling slider (I don’t know what that changes under the hood). But you can see in the attached image what the color boxes look like at 100% vs what happens when scaling goes up to 150%. The larger the scaling percentage, the bigger the color boxes get.

**facelessuser** · September 21, 2016, 2:47pm

@wbond, one thing I 've noticed on my 4K setup is that image distortion is back; notice the how some borders are thicker than others:

With that said, I don’t see the large image issue, at least not on my 4K setup; I’m using 125% scaling on Windows 7.

I will try out my Windows 10 machine tonight, but I am also using a scaling hack/app that let’s me scale things like they did in Windows 7, so I’m not sure how that will turn out.

**wbond** · September 21, 2016, 3:01pm

If you are running at 125% perhaps the pixel dimensions of your images are not equaling the pixels on your screen? If you can paste the HTML, CSS and one of the images here, I can try and dig into see why it may be displayed that way.

The most recent distortion I recall was caused by the image being taller than the line-height, and the code calculating the padding to account for the line height was resulting in negative padding. This looks like a different issue.

There of course was a change when we fixed rendering all non-font CSS dimensions as device-independent pixels on Windows and Linux instead of as device pixels. This is how OS X has always done it, since the OS takes care of the scaling. This is why I am guessing it is some sort of interplay between the scale (125%) and device pixels. I would imagine that the ST codebase should handle painting your image with interpolated pixels, but that is why the CSS, HTML and image would help. Otherwise I may find working examples that are just different than the non-working code you have.

**facelessuser** · September 21, 2016, 4:19pm

I’ll try to post a simple example later today.

**facelessuser** · September 21, 2016, 4:38pm

@jcberquist, As I recall, Windows 10 scales GUI stuff very different to how they used to. So much so that I found it very annoying. Some apps had blurry graphics that weren’t blurry in Windows 7 (I think they double the size of graphics similar to Apple retina, but I found many apps incompatible with these changes). The more I think about this, the more I’m fairly certain this issue is most likely Windows 10 specific. When I verify on my Windows 10 machine, I will probably also disable my scaling hack/app that reverts things to the Windows 7 way to be sure.

**facelessuser** · September 22, 2016, 2:44pm

Unfortunately, I missed reporting before ST’s next beta, but I am very much convinced that ST has introduced new image sizing issues (not like the one that was just fixed, but like previous issues before that). Looks to be stretching images in the X and/or Y directions. Hopefully I will get around to posting a stripped down example tonight.

Still haven’t had a chance to test out scaling on Windows 10, but hopefully tonight as well, been a busy week for me.

**facelessuser** · September 23, 2016, 3:10pm

I do have an answer now for why we are getting larger than normal images in ColorHelper.

The reason the scale factor in mdpopups isn’t working is because 1) images where never affected by the font scale. Images are sized based on line height. The reason why fonts are aren’t affected by recently by scale height is because mdpopups had implemented its own relative fonts, but in recent builds, Sublime provided its own relative font units. So in the latest builds, mdpoups uses Sublime’s relative font implementation by default instead of our cobbled together hack. You would have to change the default CSS to take advantage of the old font scale hack, but this is not recommended as the Sublime implementation is better and is the recommended way. So in short, I incorrectly recommended changing the font scale for recent builds. I simply forgot about these changes.
Images are large because Sublime is now reporting line heights as 2X bigger in Windows 10 (have not tried Linux) than other OS’s (this is only in the very latest Sublime builds that added hi def support for Windows and Linux).

So I need to now detect Windows 10 systems with hi def screens. Python isn’t quite reporting a helpful windows version, but I am sure I should be able to figure out detection of Windows 10 systems from Windows 8 systems soon.

What is more difficult is telling when Sublime is being used on a 4k system. @wbond, @jps can we please get an API check that mentions when Sublime is in hidpi mode?

In the short term, I will work on detecting Windows 10 systems and provide a setting that can be toggled in either mdpoups or the plugin of interest (I’ll have to see where it makes sense – mabye I’ll provide a function in mdpopups that gives a useful line height) so we can calculate image height properly.

**facelessuser** · September 23, 2016, 3:12pm

@wbond image distortion so far seems specific to Windows 7 (on my 4K screen - havent tested on non-4K) for me. It sees to be fine on Windows 10.

**wbond** · September 23, 2016, 3:31pm

Are you referring to View.line_height()? If so, I will get that fixed. It should always return device-independent pixels (DIP), such as how CSS in minihtml deals with DIP instead of device pixels.

Without knowing more info about why, my general answer would be that this sounds like a bad idea. Sublime Text should deal with all of the scaling and resolution issues itself, and exposing this sort of thing I think it likely to result in hacks that we have to try and work around. It is certainly possible there are completely valid reasons to know this – so please tell me!

**wbond** · September 23, 2016, 3:32pm

Ok, I’ll look into getting my Windows 7 VM to run at HiDPI and check it out.

**facelessuser** · September 23, 2016, 4:18pm

I wanted to know when we where in hidpi mode so I could divide line_height by 2, but sense this will be addressed, this is no longer needed. I wasn’t sure if this would be addressed directly or not. Thanks for looking into this!

**facelessuser** · November 6, 2016, 3:26am

ColorHelper 2.2.0

Released Nov 5, 2016

New: Add support for stTheme and search cdata #59.
NEW: Workaround for Windows 10 HiDpi large image issue #61.
See document for more info.
NEW: Added toggle support for left/right positioned previews #65.
See document for more info.
FIX: Web Color insertion bug #62.
FIX: Preview duplication bug (hopefully – please report if not fixed) #57.

**kaosmos** · November 6, 2016, 11:39am

thank you, I love this one!
And, by the way, I immediately set it to “right”

**facelessuser** · November 7, 2016, 2:37am

You’re welcome .

ColorHelper 2.0.0

ColorHelper 2.2.0