[vim/vim] respect lpDx advance widths in DirectX rendering (PR #19254)
mattn
Problem
When using DirectX rendering (set renderoptions=type:directx), character positions can become misaligned with what Vim expects.
Cause
The Win32 GUI computes advance widths for each character as the lpDx array and passes it to DWriteContext::DrawText(). These values represent the "correct" character positions as determined by Vim, based on wcwidth() and gui.char_width.
However, lpDx was not passed through TextRendererContext to AdjustedGlyphRun. As a result, the DirectX side ignored lpDx and computed advance widths independently using adjustToCell() based on font metrics.
In short: "lpDx was passed but never used."
This caused a mismatch: Vim manages cursor positions and redraw regions based on lpDx, but DirectX rendered characters based on font metrics. For fonts where glyph widths differ from Vim's cell width (e.g., UbuntuMono), characters would progressively drift out of alignment.
Solution
Pass lpDx through TextRendererContext to AdjustedGlyphRun, and use the advance widths provided by Vim instead of computing them from font metrics.
You can view, comment on, or merge this pull request online at:
https://github.com/vim/vim/pull/19254
Commit Summary
- 0db7958 respect lpDx advance widths in DirectX rendering
File Changes
(1 file)
- M src/gui_dwrite.cpp (27)
Patch Links:
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
mattn
@mattn pushed 1 commit.
- 76d680c remove negative lfHeight handling
—
View it on GitHub or unsubscribe.
You are receiving this because you are subscribed to this thread.
mattn
mattn left a comment (vim/vim#19254)I found one another issue about DirectX. When using DirectX rendering (renderoptions=directx), multi-byte characters appeared larger than expected, and scrolling left artifacts (ghosting) at the top or bottom edges of characters.
The original code had two different paths for handling lfHeight:
- Negative
lfHeight: Simply used the absolute value as font size (representing em units) - Positive
lfHeight: Converted cell height to em units using font metrics
When negative lfHeight was used, the code skipped the proper cell height conversion, resulting in an oversized font. Characters rendered larger than the cell height, causing parts of glyphs to extend beyond their allocated space. During scrolling, these overflow regions weren't properly cleared, leaving visible artifacts.
So removed the conditional logic and always calculate font size based on font metrics (ascent + descent). This ensures consistent, accurate sizing regardless of lfHeight sign, keeping characters within their designated cell boundaries.
Characters now render at the correct size, fitting properly within cell height, eliminating scrolling artifacts for multi-byte characters.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
mattn
@mattn pushed 0 commits.
You are receiving this because you are subscribed to this thread.
