Smooth caret animation lags and overlaps text when typing fast

[NicolasVitorP]

Type: Bug

Description of the Issue

There is a noticeable synchronization lag between character rendering and the cursor's visual position. This is especially prominent when the following settings are enabled:

• "editor.cursorSmoothCaretAnimation": "on"
• "editor.cursorBlinking": "expand"

While the editor renders characters instantly, the cursor follows a fixed-duration sliding and expansion animation. During fast typing, this causes a "clipping" effect:

1. Physical Overlap: The cursor bar physically passes through the body of the letters because it is still animating toward the new position while the next character has already appeared.
2. Visual Obstruction: Since the blinking is set to "expand", the visual footprint of the cursor is larger during the transition, causing it to overlap and obscure the newly typed characters even more.
3. Input Lag Sensation: This creates a distracting visual flicker and makes the UI feel "heavy" or out of sync with the user's actual typing speed.

---

Steps to Reproduce

1. Open settings and set "editor.cursorSmoothCaretAnimation": "on".
2. Set "editor.cursorBlinking": "expand".
3. Type at a fast, sustained pace.
4. Observe the cursor "cutting" through the characters.

---

Expected Behavior

The cursor animation should be dynamic. If a new character is typed before the previous animation finished, the cursor should either:

• Accelerate to the new position instantly.
• Cancel/Skip the current animation to ensure the bar never overlaps or stays behind the rendered text.

---

Technical Context

Setting	Configuration
Animation	cursorSmoothCaretAnimation: "on"
Blinking Style	cursorBlinking: "expand"
Issue Type	Visual Desync / UI Lag

VS Code version: Code 1.109.4 (c3a2684, 2026-02-16T15:35:57.932Z)
OS version: Windows_NT x64 10.0.26200
Modes:

System Info

Item	Value
CPUs	AMD Ryzen 5 5500U with Radeon Graphics (12 x 2096)
GPU Status	2d_canvas: enabled GPU0: VENDOR= 0x1002, DEVICE=0x164c [AMD Radeon(TM) Graphics], DRIVER_VENDOR=AMD, DRIVER_VERSION=30.0.13014.8 ACTIVE GPU1: VENDOR= 0x1414, DEVICE=0x008c [Microsoft Basic Render Driver], DRIVER_VERSION=10.0.26100.7309 Machine model name: Machine model version: direct_rendering_display_compositor: disabled_off_ok gpu_compositing: enabled multiple_raster_threads: enabled_on opengl: enabled_on rasterization: enabled raw_draw: disabled_off_ok skia_graphite: disabled_off trees_in_viz: disabled_off video_decode: enabled video_encode: enabled webgl: enabled webgl2: enabled webgpu: enabled webnn: disabled_off
Load (avg)	undefined
Memory (System)	15.39GB (7.68GB free)
Process Argv	--crash-reporter-id b1f76865-a5aa-4112-9605-a426f5e77887
Screen Reader	no
VM	0%

Extensions (14)

Extension	Author (truncated)	Version
codesnap	adp	1.3.4
path-intellisense	chr	2.10.0
gitlens	eam	17.10.0
vscode-html-css	ecm	2.0.14
EditorConfig	Edi	0.18.1
prettier-vscode	esb	12.3.0
auto-rename-tag	for	0.1.10
code-runner	for	0.12.2
fluent-icons	mig	0.0.19
vscode-language-pack-pt-BR	MS-	1.108.2026021109
color-highlight	nau	2.8.0
LiveServer	rit	5.7.9
charmmono-theme	sum	0.3.1
errorlens	use	3.28.0

(1 theme extensions excluded)

A/B Experiments

vsliv368:30146709
pythonvspyt551:31249599
binariesv615:30325510
nativeloc1:31344060
dwcopilot:31170013
dwoutputs:31242946
copilot_t_ci:31333650
e5gg6876:31282496
pythonrdcb7:31342333
6518g693:31436602
aj953862:31281341
6abeh943:31336334
cloudbuttont:31379625
3efgi100_wstrepl:31403338
use-responses-api:31390855
ec5jj548:31422691
cp_cls_t_966_ss:31454198
4je02754:31458170
find_all_ref_in_bg_t:31453034
a5gib710:31434435
7a04d226_do_not_restore_last_panel_session:31438103
406hc587_ask_agent:31428393
cp_cls_c_1081:31454833
a43f0575b:31442825
e9c30283:31461165
edit_mode_hidden:31461530
864ei723_large_tool_results_to_disk:31460878
notips:31457203
ei9d7968:31458072
chat:31457767

[Yoyokrazy]

cc/ @jo-oikawa for UX and CSS thoughts on this, afaik this is handled on that side so might be a UX issue?

[NicolasVitorP]

cc/ @jo-oikawa for UX and CSS thoughts on this, afaik this is handled on that side so might be a UX issue?

Hi @Yoyokrazy, following up on this. Since the ux-feedback-wanted label was added 4 days ago, I'd like to know if there's an official stance or an ongoing investigation regarding a fix.

The 'clipping' is a persistent issue for fast typing speeds. Is this currently being prioritized for an upcoming sprint, or is it still in the evaluation phase with @jo-oikawa?

[Yoyokrazy]

Right now this is in the backlog and isn't a primary focus. It's pending a discussion on priority, but it's unlikely that we get to this in the near future. You're welcome to contribute and put up a PR, and we will try to find time to review alongside or current iteration items.

[NicolasVitorP]

Right now this is in the backlog and isn't a primary focus. It's pending a discussion on priority, but it's unlikely that we get to this in the near future. You're welcome to contribute and put up a PR, and we will try to find time to review alongside or current iteration items.

Thanks for the update, @Yoyokrazy. I understand the backlog situation, and I appreciate the transparency.

I'd like to make a concrete case for why I believe this deserves higher priority:

1. It directly interferes with error detection
When the cursor overlaps characters during fast typing, developers lose the ability to spot typos in real time. The cursor — which is supposed to act as a visual anchor — becomes noise instead of a guide. This forces users to slow down or re-read lines they've just typed, breaking their flow.

2. It causes measurable cognitive fatigue
The brain constantly tries to reconcile two conflicting signals: where the cursor is visually vs. where it should be. Over an 8-hour workday, this persistent low-level visual desync accumulates into real mental strain. It's the same principle behind why flickering screens cause headaches — the eye is chasing something unstable.

3. It makes VS Code feel broken to new users
Someone setting up VS Code for the first time, following a popular YouTube guide or dotfiles tutorial (many of which recommend exactly this combination of settings), will immediately notice the glitch. Their first impression is that the editor is laggy or poorly optimized — not that there's a known bug. That's a retention and perception problem.

4. It contradicts the purpose of the feature itself
cursorSmoothCaretAnimation exists to make the experience feel more polished and professional. When combined with cursorBlinking: expand, it does the opposite — it actively degrades the experience during the exact moment that matters most: when the user is actively typing. The feature is undermining its own goal.

5. It's invisible in issue count but widespread in practice
Most users don't file bug reports — they just disable the settings, switch editors, or silently accept the glitch. The low issue count does not reflect real exposure. This combination of settings appears in hundreds of shared dotfiles and config tutorials online, meaning the actual affected user base is far larger than GitHub activity suggests.

I'm not asking for a drop-everything fix. But given that this affects the core typing experience — the single most repeated action in a code editor — I believe it warrants being scheduled for a near-future iteration rather than sitting indefinitely in the backlog.

Thanks for considering it.

[jo-oikawa]

Sorry @NicolasVitorP - I added both setting and am not seeing this repro for me? Are you seeing this issue on a certain type of file? Are there any other relevant settings you have enabled? Can you provide a recording to show the issue you're seeing?

Here's a screen recording:

Screen.Recording.2026-02-25.at.11.35.50.AM.mov

[NicolasVitorP]

Sorry @NicolasVitorP - I added both setting and am not seeing this repro for me? Are you seeing this issue on a certain type of file? Are there any other relevant settings you have enabled? Can you provide a recording to show the issue you're seeing?

Here's a screen recording:

Screen.Recording.2026-02-25.at.11.35.50.AM.mov

Hi @jo-oikawa, thanks for testing it out!

To answer your questions: the issue happens on any file type — I've reproduced it consistently on .html, .js, and plain text files. There's no specific file type required.

I'm attaching a recording that shows the overlap happening during fast typing. The cursor visibly lags behind the rendered characters and clips through them before settling into position.

[recording attached above]

One thing worth noting: the effect may be more or less prominent depending on monitor refresh rate, GPU, or system load. I'm on Windows 11 (x64). Let me know if you need any additional info!

[NicolasVitorP]

@jo-oikawa,

To help with reproduction, the issue becomes most apparent during sustained, high-frequency input. A reliable way to trigger it is to press and hold a single key (e.g., 'z' or 'a') so that the repeat rate kicks in.

In the recording I attached, you can see that when characters are generated rapidly, the 'expand' animation hasn't finished its transition to the previous character's position before the next one appears. This causes the cursor to 'slice' through the text. It seems the cursor animation has a fixed duration that doesn't scale or cancel when the typing speed exceeds the animation's frame budget.

[stormherz]

I'm having the same issue, also on Windows 11 (not sure if it matters much, but still)

@NicolasVitorP have very strong points there

On top of that - it's definitely is or strongly becoming a trend to have a gpu-based support in a modern editor. I can definitely agree that it's not the highest priority of them all, but still deserves some digging, especially if it can be fixed somewhat easily