In all cases the primary cursor is "painted" as a <div> of width 2px. Chromium ultimately decides how to "zoom in" to respect the OS settings (possibly by multiplying everything with 1.25, and then proceeding to snap to real screen pixels).

AFAIK there is no possible code change we can do on our side to workaround this snapping / rounding-error quirks. I am thinking this is reproducible using Chrome at https://jsfiddle.net/b4hkeLew/ It is just a matter of playing with the left offset position until the snapping / rounding-error happens.

@alexandrudima Interesting, that explains why there's no artifacts at 150% zoom (because it yields 3px exactly). And why there still are artifacts at 150% with "editor.cursorStyle": "line-thin".

Look at this though: https://jsfiddle.net/655jcnmf/2/ when I specify 1.6px width (2 / 1.25), there's no width artifacts!

So, if you could somehow determine OS DPI and also keep track of your own zoomLevel, you could pre-round line width based on that and use it everywhere.

Or at least it would be nice if you exposed it as some sort of an advanced option. Because vscode is otherwise Literally Unplayable™ for me without tweaking anyway, and I'd prefer a tweaking option that reliably works with any zoomLevel (especially 0).

I have been down this road only last week. The problem is that I could not come up with any formula that makes sense and uses the values I have at my disposal: window.devicePixelRatio, document.createElement('canvas').getContext('2d').webkitBackingStorePixelRatio which when divided should give the pixelRatio; zoomLevel or zoomFactor.

Perhaps I am missing something obvious but here is what I observed on a mac book pro's built-in monitor:

See https://github.com/Microsoft/vscode/blob/91a0e04417cabaeda04bc20891d58ae338179f66/src/vs/editor/browser/controller/textAreaHandler.ts#L423

// Observed values on a retina screen (by taking screenshots):
// |--------|-----------|------------|------------|-----------|
// | css px | zoomLevel | zoomFactor | pixelRatio | screen px |
// |--------|-----------|------------|------------|-----------|
// |   18   |    -8     |   0.2325   |   0.5000   |      8    |
// |   18   |    -7     |   0.2790   |   0.5581   |     10    |
// |   18   |    -6     |   0.3348   |   0.6697   |     12    |
// |   18   |    -5     |   0.4018   |   0.8037   |     14    |
// |   18   |    -4     |   0.4822   |   0.9645   |     18    |
// |   18   |    -3     |   0.5787   |   1.1574   |     20    |
// |   18   |    -2     |   0.6944   |   1.3888   |     26    |
// |   18   |    -1     |   0.8333   |   1.6666   |     30    |
// |   18   |     0     |   1.0000   |   2.0000   |     36    |
// |--------|-----------|------------|------------|-----------|

I found this: https://chromium.googlesource.com/chromium/src.git/+/refs/heads/lkcr/content/common/page_zoom.cc

And the formula there matches your observed zoomFactor perfectly and pixel values pretty close (if we assume a 2x factor coming from the device DPI or something):

edit: and pixelRatio = zoomFactor * 2, except it's limited to a minimum of 0.5 (or 0.25 as per the linked code, with the 2x factor coming from somewhere else)

for zoomLevel in range(-8, 1):
    zoomFactor = 1.2 ** zoomLevel
    print(f'{zoomLevel:>2} | {zoomFactor:0.4f} |  {2 * zoomFactor:0.4f} | {36 * zoomFactor:>5.2f}')
====================
-8 | 0.2326 | 0.4651 |  8.37
-7 | 0.2791 | 0.5582 | 10.05
-6 | 0.3349 | 0.6698 | 12.06
-5 | 0.4019 | 0.8038 | 14.47
-4 | 0.4823 | 0.9645 | 17.36
-3 | 0.5787 | 1.1574 | 20.83
-2 | 0.6944 | 1.3889 | 25.00
-1 | 0.8333 | 1.6667 | 30.00
 0 | 1.0000 | 2.0000 | 36.00

(also, this means that I was wrong about the way zoom works, and it worked for me both times accidentally, because 1.25 * (1.2 ** -1.25) = 0.995 while the correct zoomLevel to counteract 125% zoom is -1.2239)

edit2: also I checked, at least on JSFiddle window.devicePixelRatio shows 1.25 to me (at normal zoom), so it already takes into account system DPI, so I guess you can just go and use it? And ignore the maybe applied but maybe not cutoff at zoomFactor: -8.

Thank you for looking and helping out with this. To sum up:

• zoomFactor = Math.pow(1.2, zoomLevel)
• window.devicePixelRatio = Math.max(0.5, Math.min(5, zoomFactor * systemRatio)) (for the screen I measured with systemRatio appears to be 2)
• screenPx = window.devicePixelRatio * cssPx with the extra constraint that rounding depends on how the dom node "aligns" to the screen pixels. i.e. it depends on what is the left and the width of the dom node. I think that's why 17.36 is rounded to 18 in my measurements.

So we could programmatically set the cursor width with the following formula:

function dpiAwareSize(cssPx) {
  var screenPx = window.devicePixelRatio * cssPx;
  return Math.max(1, Math.round(screenPx)) / window.devicePixelRatio;
}

The idea is that we don't want to have the cursor be always 2 screen pixels. If the user zooms in at 200%, the cursor should be 4 screen pixels, or at least I think that's what we'd want. In your case it would be Math.round(1.25 * 2) / 1.25 = 2.5. So we would set it on our side to be 2.5px such that it will be of a constant width of 3 screen pixels.

Sounds good. By the way, this function should also be used for drawing rulers (see #9634) and the newly enabled by default Indent Guides, they too are drawn with varying screen widths for me.

The function from above appears to work fine -- Windows at 125% zoom: