Zoom offsets the visible cursor

[W4RH4WK]

I recently noticed a bug where the visible editing cursor and selection are offset to where VSCode thinks the cursor is. This happens when zooming in and seems to be dependent on the font you are using.

The bug happens for me when using the Hack Font under Linux. Using that font under Windows did not result in an offset of the cursor / selection. Using Ubuntu Mono as my font did not trigger the bug, nor was increment the font size instead of zooming.

The following pictures illustrate the issue:

Correct selection using Ubuntu Mono:

Offset selection using Hack:

In both cases node.getRight() has been selected and hitting backspace will delete it.

This also happens around the 80 column mark, not just far to the right, note the cursor ontop of the equal sign:

• VSCode Version: 1.12.1
• OS Version: Ubuntu 16.04 LTS

Steps to Reproduce:

1. Setup VSCode to use Hack as font.
2. Open a file with content.
3. Zoom (bug may only trigger on some zoom levels).
4. Select text.

Maybe Related:

• cursor appearing on wrong position when beyond 300 in php file #22181

[alexdima]

@W4RH4WK

We do some probing to determine if the font is monospace and determine the character width, let's call it charWidth. In such cases we optimize some of the painting code to assume that the character at position N is situated at N * charWidth.

To validate this is a problem with our monospace optimizations, can you please try disabling this optimization (i.e. "editor.disableMonospaceOptimizations": true) and check if the problem reproduces?

[W4RH4WK]

@alexandrudima yes, with that optimization disabled cursor and selections are at the correct position when zoomed.

[alexdima]

@W4RH4WK

I have just tried on Ubuntu 16.04 + Hack + zoom level 1 and 2 and I could not reproduce. Could you please share all your settings? Perhaps it happens at a certain fontSize ?

{
    "window.zoomLevel": 2,
    "editor.fontFamily": "Hack"
}

[W4RH4WK]

When I took the screenshot I had the following settings:

{
    "editor.fontFamily": "Hack",
    "editor.fontSize": 16,
    "window.zoomLevel": 4
}

I am on Ubuntu 16.04 too and uploaded the file I used as example: https://gist.github.com/W4RH4WK/caeabf814c482d660b3f4c8f92a278a3

[xremming]

On Ubuntu 16.04, running 1.12.1, having the same problem. I get this on all files, but only on certain zoom levels.

Font family: 'Droid Sans Mono', 'Courier New', monospace, 'Droid Sans Fallback'
Font size: 14

[alexdima]

I'm sorry I could still not reproduce. I also tried rendering whitespace, since those might impact things too (and I've noticed whitespace being rendered in one of the screenshots).

When I go zoomLevel: 5, around column 900 I can notice the coordinates obtained through multiplication being a few px off from the actual rendered text:

I think I noticed some of these rounding errors in the past, so the fast view line (the one that uses multiplication) only kicks in for lines under 1000 chars: https://github.com/Microsoft/vscode/blob/master/src/vs/editor/browser/viewParts/lines/viewLine.ts#L189 , but I never saw anything quite as bad as your screenshots.

@W4RH4WK @PolarPayne
Is there something more to it? i.e. I use Ubuntu + Unity on a regular monitor. Could it be reproducible with a different window manager? Do you use a 4k monitor or something? Does Ubuntu support some DPI settings that might influence this?

[alexdima]

Hmm, actually I could reproduce some weirdness in a VS Code session immediately after changing the zoom level. i.e.: change the zoom level, the positions are off. It all went away after restarting VS Code. I think there might be some sort of race between when the font is measured and the zoom level is applied. @PolarPayne @W4RH4WK Does this issue resolve itself after closing VS Code and starting it up again?

[alexdima]

My repro steps:

• settings:

{
    "editor.fontFamily": "'Droid Sans Mono', 'Courier New', monospace, 'Droid Sans Fallback'",
    "editor.fontSize": 14,
    "window.zoomLevel": 5
}

• close VSCode
• start VSCode
• comment out window.zoomLevel and save
• Observe cursor position being off for the remaining of the window session (i.e. until vs code is restarted)

The root cause appears to be:

• we call webFrame.setZoomLevel(0) when we detect the settings change.
• we then call browser.setZoomLevel(webFrame.getZoomLevel()) which evaluates to 0 as expected.
• even though webFrame.getZoomLevel() returns 0, it appears the web frame is still at zoom level 5 for some time
• we then proceed to re-read the font width meansurements believing we are at zoom level 0.
• we end up reading the font width values corresponding to zoom level 5 because the webFrame didn't really apply the new zoom level yet even if it says it did.

[xremming]

This is happening both with my 1920x1080 and 2560x1440 displays (that's how I noticed this also, since I'm moving the window between the screens and then I need to zoom in/out), also I'm using i3.
If I restart vscode, and scroll a bit and move the cursor it seems to fix it (but only after scrolling?).

Before restart:

After restart:

The more I test and try this the weirder it gets. Now I enabled editor.mouseWheelZoom, and that doesn't touch window.zoomLevel variable and only applies the zoom to the editor part this is also not remembered between restarts??? (I guess this might be another bug if so I'll create another issue from this)
Anyway, with mouseWheelZoom this seems to be a lot harder to reproduce, but it's still there.

[alexdima]

Upstream issue: electron/electron#9418

[alexdima]

@PolarPayne VS Code supports two types of "zoom":

• one is conceptual similar to the browser zoom. i.e. View > Zoom In / Zoom Out. This makes it that everything gets zoomed in (including icons, etc.). This is the kind of zoom that triggers this issue
• the other editor.mouseWheelZoom is simply multiplying the editor fontSize behind the scene. This is what most other desktop text editors refer to as zooming. This is the kind of zoom that does not trigger this issue.