I’ll inspect the mintty patch history and rendering hot paths first, then compare against wezterm/ghostty rendering/update strategies and pull out concrete candidate experiments rather than code changes.

Noted. With Ligatures=0, the ASCII Uniscribe bypass and ASCII run merging are directly relevant. With DisplaySpeedup=0, I’ll ignore frame-dropping/throttling as a primary “optimization” and focus on reducing work per full refresh / update.

I found several plausible candidates. The biggest one is not compiler flags; it is avoiding repainting/copying work during scroll/full-refresh cases, then shaving CPU work inside the ASCII path you now hit with Ligatures=0.

I only did static inspection / grepping, not code changes or benchmarks.

What your patch already attacks

The current patch series already hits the obvious hot paths:

With your settings, Ligatures=0 means unshaped_ascii is true in src/term.c, so the ASCII run merge and ExtTextOutW bypass are active. DisplaySpeedup=0 means the frame-skip path in do_update() is not a performance strategy here.

Best candidate: resurrect display scrolling, but into the back buffer

There is an inactive scroll-optimization scaffold in src/term.c:

• use_display_scrolling is disabled.

• disp_scroll() / disp_do_scroll() exist.

• disp_do_scroll() wants to call win_do_scroll(topscroll, botscroll, lines).

• I did not find a win_do_scroll implementation.

That is the highest-upside target for “large terminals doing full refreshes” and high-DPI screens.

Right now, scroll-heavy output appears to do roughly this:

1. terminal model scrolls,

2. lines_scrolled += lines,

3. paint eventually walks/redraws visible rows,

4. back buffer is blitted to the window.

For normal full-width scroll regions, a better fast path is:

1. scroll/copy the affected rectangle inside paint_buf_dc,

2. rotate/update term.displines,

3. invalidate only newly exposed rows,

4. still do one coherent final BitBlt to the real window.

That preserves your tearing fix because the window still only sees the final buffer copy, but it avoids redrawing all shifted rows. This should matter a lot for huge windows and HiDPI because the shifted area is mostly identical pixels.

I would start with a deliberately narrow fast path:

• full-width scroll region only,

• no left/right margin mode,

• normal LATTR_NORM lines only,

• no background image / sixel / emoji overlay interaction at first,

• no search-bar exclusion complication,

• no double-height / double-width line attributes,

• copy one contiguous scroll rectangle in the back buffer,

• mark exposed rows dirty.

This is probably the most mintty-shaped version of what GPU terminals get “for free” by retaining/copying scene data.

Next candidate: dirty row bitset instead of one dirty top/bottom span

Your buffered path tracks:

• paint_dirty_top

• paint_dirty_bot

and win_paint_buffer_end() blits one contiguous span.

That is simple and good, but it over-blits whenever dirty rows are sparse. Cursor blink, selection updates, search highlights, IME/composition, or small changes near top and bottom can force a tall HiDPI blit.

Candidate: track a dirty row bitset, then in win_paint_buffer_end() coalesce contiguous dirty row runs:

rows dirty: 3,4,5,30,31,80
blits:      3-5, 30-31, 80

Use a heuristic:

• if dirty row runs are few, issue multiple BitBlts;

• if many rows are dirty, collapse to the existing single span.

For full-screen refreshes this will not help much, but for mixed workloads on huge terminals it prevents “almost full-window” copies caused by two distant dirty rows.

ASCII hot path: avoid repeated bidi_class() for boring ASCII

Even after the ASCII merge, the drawing loop in src/term.c still does per-cell classification work. Around the render loop, it calls bidi_class(xtchar) before deciding whether to break runs. bidi_class() in src/minibidi.c is a table search over Unicode ranges.

With Ligatures=0, most printable ASCII cells do not need full bidi classification for the “continue same ASCII run” case. The current code already has logic like “if both previous and current are ASCII, don’t break on bidi class,” but it still computes the class first.

Candidate:

• add an ASCII fast path before bidi_class();

• for unshaped_ascii && current_ascii && previous_ascii, skip full bidi classification;

• only compute the class at ASCII/non-ASCII boundaries or when non-ASCII is involved.

This is a CPU-side improvement, not GDI-side. It should show up most on full repaint of ASCII-heavy terminals.

Line-level render cache, inspired by wezterm/ghostty

WezTerm and Ghostty both avoid rebuilding more render state than necessary. Ghostty’s render state has retained row data and dirty tracking, with a two-phase update path designed to keep terminal locking and update work bounded; it also has helpers that scan grouped cells for dirty/special handling. GitHub GitHub

WezTerm goes further with CPU-side caches:

• line shape hash,

• shaped line element cache,

• line quad cache,

• glyph cache.

Mintty cannot copy the GPU architecture, but the useful idea is still valid: cache per-line render decomposition.

Mintty currently appears to rebuild runs from terminal cells during paint. A line-level generation/hash could let you cache:

• run boundaries,

• font/style attributes,

• “boring ASCII” classification,

• whether line contains RTL / wide / combining / emoji / overhang-sensitive content,

• maybe precomputed dxs shape for simple runs.

Then invalidate on:

• cell edit,

• scroll exposure,

• font / DPI / config generation,

• selection/cursor/search overlay changes,

• emoji/image/combining interactions.

This is more invasive than the scroll-copy path, but it addresses the “large full refresh” CPU cost directly.

A smaller first version: add only a per-termline sequence number and counters to learn how many “repainted” rows are logically unchanged.

GDI state-call memoization inside win_text()

win_text() still does many per-run GDI state calls:

• SelectObject(dc, font)

• SetTextColor(dc, fg)

• SetBkColor(dc, bg)

• SetBkMode(...)

• SetDCBrushColor(dc, bg)

On large ASCII refreshes, the number of runs is reduced but still non-trivial. Tracking the last selected font / fg / bg / brush color / background mode per paint DC could avoid redundant calls.

This is low-risk if scoped carefully:

• reset cache when the HDC changes,

• reset after helper functions that use temporary DCs,

• reset around any path that may mutate DC state unexpectedly,

• keep correctness over cleverness.

Expected gain is modest, but this is the kind of GDI overhead that accumulates.

Guarded lpDx == NULL experiment for “boring monospaced ASCII”

win_text() builds an int dxs[len] array and passes it through text output. For truly boring primary-font ASCII, that may be unnecessary.

Microsoft documents that ExtTextOut can use default spacing when lpDx is NULL; the lpDx array is for explicit character-spacing/origin control. Microsoft Learn

Candidate fast path:

• primary font,

• printable ASCII only,

• no combining,

• no overstrike,

• no wide chars,

• no char spacing option,

• no scaling/stretch case,

• normal cell width equals font advance,

• Ligatures=0,

• not using Uniscribe.

Then try ExtTextOutW(..., lpDx=NULL) or TextOutW.

This needs pixel-exact tests. Terminal alignment bugs are easy here. But if it works, it avoids filling dxs[] and gives GDI the simplest possible text path.

Back buffer: test CreateDIBSection vs compatible bitmap

The double buffer currently uses CreateCompatibleDC() plus CreateCompatibleBitmap(). That usually means a device-dependent bitmap unless the source DC already has a DIB section selected. Microsoft documents CreateDIBSection as creating a bitmap with app-accessible bits. Microsoft Learn

Candidate experiment:

• use a top-down 32-bit DIB section for the persistent paint buffer;

• keep rendering text with GDI into the memory DC;

• measure:

  • text output into DIB section,

  • background fills,

  • final BitBlt,

  • resize behavior,

  • HiDPI bandwidth.

This could be faster or slower. DIBs are attractive for predictable memory layout and direct clearing, but GDI text into a DIB section may underperform a device-compatible bitmap on some systems. I would benchmark it, not assume it wins.

Non-ASCII shaping: cache or bypass more, but lower priority for your config

Your patch already avoids Uniscribe for blank and printable ASCII. That matters because ScriptStringAnalyse does substantial work: it allocates internal buffers and performs itemization, shaping, placing, and breaking. Microsoft Learn

Remaining candidates:

• cache “this run definitely does not need Uniscribe” classification;

• bypass Uniscribe for box drawing / block elements / simple CJK runs if correctness tests pass;

• cache shaped results for repeated non-ASCII runs.

I would be careful caching SCRIPT_STRING_ANALYSIS itself. The object is opaque, allocated by Uniscribe, tied to analysis parameters, and must be freed. A mintty-side cache of simpler metadata is probably safer than retaining Uniscribe objects.

Background fill batching

Even with stock DC_BRUSH, there is still a fill per background run. Large full refreshes with lots of color changes will pay for that.

Possible architecture:

1. background pass: merge adjacent same-background rectangles per row;

2. text pass: draw foreground only;

3. special decorations pass.

This is invasive because mintty currently folds background, overhang, clipping, underline, selection, and text output together. It might help color-heavy workloads but is lower priority than scroll-copy and ASCII CPU reductions.

Low-confidence: PolyTextOutW

PolyTextOut can draw multiple strings with the currently selected font and colors. Microsoft Learn

It might batch foreground text runs after a separate background pass. But because mintty has per-run clipping, backgrounds, dx arrays, Uniscribe fallback, overhang handling, wide chars, combining chars, and font fallback, this looks like a larger refactor with uncertain payoff.

I would not chase it first.

Instrument before changing much

The useful counters would be:

• term_paint rows scanned,

• dirty rows found,

• rows actually drawn,

• win_text() calls,

• chars passed to win_text(),

• ASCII vs non-ASCII chars/runs,

• bidi_class() calls,

• win_char_width() cache hits/misses,

• ScriptStringAnalyse() calls and time,

• ExtTextOutW() calls and time,

• FillRect() calls and pixels,

• BitBlt() calls and pixels,

• number of dirty row spans,

• scroll lines eligible for scroll-copy,

• scroll lines rejected and reason.

For your workload, I would bet the ranking is:

1. buffered scroll-copy / revive display scrolling safely;

2. ASCII bidi_class() fast path;

3. dirty row bitset / multi-span blit;

4. GDI state memoization;

5. guarded lpDx=NULL boring ASCII path;

6. line-level render-run cache;

7. DIB-section back buffer experiment;

8. non-ASCII shaping cache/bypass;

9. background batching / PolyTextOutW.

The scroll-copy path is the one I would investigate first because the disabled scaffold already exists and the payoff matches your exact problem: large terminals, full refreshes, and HiDPI pixel bandwidth.

I’ll make a focused diagnostic-only patch against the uploaded tree: low-overhead counters/timers, no rendering behavior changes, and one per-process log under C:\Temp.

I found the buffered paint/render-loop boundaries and will aggregate one compact record per update, with hooks around term_paint(), win_text(), GDI primitives, Uniscribe, and width caching.

I’m adding a MINTTY_PERF=0 kill switch and key=value log records, after resetting prior scratch edits so the diff stays instrumentation-only.

Created the instrumentation-only patch:

Download mintty-perf-instrumentation.patch

It adds src/perf.c / src/perf.h and instruments term.c + wintext.c. No render behavior changes intended.

It logs to:

C:\Temp\mintty.perf.{PID}.log

It creates C:\Temp if needed, appends to the per-PID log, flushes periodically, and closes/flushed at exit. It is enabled by default; disable with:

Bash
MINTTY_PERF=0 mintty

The log format is one key=value line per update, plus skip= lines for skipped updates. It includes counters/timings for:

update / WM_PAINT timing
term_paint timing
win_text calls/chars/phases
ExtTextOutW vs ScriptStringOut / ScriptStringAnalyse
FillRect calls/pixels/time
BitBlt calls/pixels/time
dirty rows/cells
back-buffer use/reject/recreate/stale-full-repaint
scroll calls/visible scroll opportunity lines
bidi_class calls and ASCII/non-ASCII split
run-break reasons
win_char_width cache hits/misses/uncached time
invalidate calls/cells/full-screen invalidations

I also checked:

git apply --check /mnt/data/mintty-perf-instrumentation.patch
git diff --check

and syntax-checked perf.c with stub Win32 headers. I did not do a real mintty build here because this container does not have the Cygwin/Win32 build headers.

I parsed the full log now. The headline already changed: the slow tail is dominated by non-ASCII/box-line-art rendering fragmentation, not Uniscribe shaping and not BitBlt.

The report-generation wrapper tripped over an invalid Python syntax draft; I’m rerunning with a plain Python script and the already-parsed metrics unchanged.

I parsed the full log with a script, not just the truncated preview: 4,043 records, 4,018 source=update records, 25 source=paint records, total measured update time 107.7s.

mintty.perf.2872

Generated files:

Analysis script

Main finding

The slow path is Unicode / line-art fragmentation in win_text(), not BitBlt, not Uniscribe shaping, and not normal ASCII full refresh.

The fancy tig line-art suspicion looks real on the terminal side. I cannot say how much CPU tig itself used, but the mintty log shows very large terminal paint/update costs during non-ASCII updates:

Those 214 slow non-ASCII updates are only 5.3% of updates but account for 61% of total measured update time.

Where the time went

Across all update records:

For the bad non-ASCII >100ms cohort:

So: Uniscribe is basically irrelevant in this capture. The problem is that line-art-ish non-ASCII causes massive call fragmentation:

That is the smoking gun.

Updated target ranking

1. Prime target: line-art / box-drawing “boring non-ASCII” fast path

This moves to the top.

The generic “non-ASCII shaping cache/bypass” idea should become something narrower:

Detect box drawing / block / common TUI line-art characters as monospaced boring glyphs and keep them in longer runs.

Specifically, investigate reducing breaks at ASCII/non-ASCII boundaries and attr boundaries where safe. In the slow cohort, the code is effectively doing per-cell or near-per-cell work. Even if each GDI call is cheap, millions of tiny win_text/fill calls are not.

Candidate shape:

same attr + same font + same cell width + no combining + no emoji + no bidi hazard
=> draw as one direct GDI run, even if it contains ASCII + U+2500 box chars

Do not chase Uniscribe first. The log says Uniscribe is not the bottleneck.

2. Prime target: background/fill batching for fragmented TUI rows

FillRect is not the largest standalone timer, but the slow cohort has 1.27M fill calls and 5.8s in FillRect. More importantly, those fill calls probably correlate with the unmeasured overhead inside win_text.

For line-art screens, a background pass that merges same-background rectangles before foreground text could help. This is now more interesting than it looked before.

3. Add deeper win_text() sub-instrumentation before changing too much

There is a large gap inside win_text:

slow non-ASCII cohort:
win_text      63.6s
ExtTextOutW    0.47s
ScriptOut      0.16s
Uniscribe      0.06s
FillRect       5.8s

That leaves a lot of time inside win_text not explained by the GDI calls I instrumented. Before optimizing blindly, I would add sub-counters around:

font fallback / get_font
text buffer conversion
dx array setup
rect / clipping setup
overhang handling
phase loop overhead
background path decisions
wide/non-ASCII branch decisions

But the direction is clear: reduce call count and per-cell path overhead.

4. Still worthwhile: buffered scroll-copy / revive display scrolling

This remains a good optimization, but it is not the main explanation for the painful spikes in this log.

There were 416,799 visible scroll lines across 731 scroll-visible updates, so scroll-copy still has real opportunity. But those updates totaled only 12.9s, and the worst non-ASCII spikes had scroll_visible_lines=0.

So I would still do it, but after the line-art fragmentation work.

5. ASCII bidi_class() fast path: useful but not top priority

The log shows huge scan volume:

paint_cells_seen   115.4M
bidi_class_calls   115.4M
bidi_ascii_cells   108.9M

Even sparse one-cell updates scan/classify a full screen. For example, the sparse <=10 dirty cells cohort has 1,168 updates and 5.3s total time.

So yes, add the ASCII short-circuit. But this will improve the baseline, not the painful Unicode spikes.

6. Dirty-row bitset / multi-span blit: lower priority now

Sparse updates are frequent, but cheap enough:

<=10 dirty cells:
1168 updates
5.3s total
p50 3.0ms
p95 12.1ms

A better dirty row/span model would help polish idle/cursor/small updates, but it is not where the big time is.

7. lpDx == NULL ASCII experiment: lower priority

ASCII-only is already reasonably healthy:

ASCII-only p50: 5.6ms
ASCII-only p95: 21.3ms
ASCII-only max: 57.5ms

It may still help full ASCII refreshes, but the log does not justify doing it before the non-ASCII fragmentation work.

8. GDI state memoization: not compelling from this run

Totals are tiny:

select_font_ticks_us       151ms
set_text_color_ticks_us     91ms
set_bk_color_ticks_us       91ms

There may be hidden overhead not captured here, but the measured state-change calls are not a primary target.

9. DIB-section back buffer: not compelling from this run

BitBlt moved 13.6 billion pixels but took only 3.7s total. It matters, but it is not the current wall.

Practical next move

I would pursue this sequence:

1. Instrument win_text() internals more deeply, because the slow path is inside it but not in the obvious GDI calls.

2. Prototype a box-drawing / block-character fast path that treats common TUI Unicode as direct monospaced text and merges runs aggressively.

3. Batch/merge background fills for same-background cells/runs.

4. Then do scroll-copy into the back buffer.

5. Then do ASCII bidi_class() skip and small-update scan reductions.

The current data says the fastest win is not “make GDI faster”; it is stop feeding GDI and win_text() millions of tiny fragments for Unicode TUI screens.

I’ll apply the prior instrumentation patch to a fresh mintty tree, inspect win_text() structure, add deeper counters without changing render behavior, then emit a second patch that applies cleanly on top of the previous one.

The likely missing bucket is now clearer from the code: self-drawn box/block graphics allocate/copy/free a temporary text buffer, create pens/brushes/clip regions, and run GDI line/fill primitives, none of which the first patch timed deeply.

Done:

Download mintty-perf-wintext-deep-instrumentation.patch

This patch applies on top of mintty-perf-instrumentation.patch.

I checked:

Bash
git apply /mnt/data/mintty-perf-instrumentation.patch
git apply --check /mnt/data/mintty-perf-wintext-deep-instrumentation.patch
git apply /mnt/data/mintty-perf-wintext-deep-instrumentation.patch
git diff --check -- src/perf.h src/perf.c src/wintext.c

I also syntax-checked src/perf.c with a fake Win32 header. I still could not do a real Cygwin/Win32 mintty build in this container.

The new fields focus on the missing win_text() buckets:

font/attribute setup
origtext alloc/free for self-drawn chars
dxs and ulen setup
Uniscribe decision overhead
background clearing / background image path
coordinate transforms
SetBkMode / SetDCBrushColor
plain vs combining textout path
self-drawn boxpower / boxcoded / vt52 timings
clip region creation/selection/deletion
self-drawn FillRect pixels/ticks
line/rect/polygon/chord/AngleArc/SetPixel operation counts
GDI pen/brush/region/select/delete object counts

This should make the next log identify whether the Unicode TUI spikes are mostly:

per-cell origtext allocation/free
per-run pen/brush/clip region churn
LineTo / manual box drawing volume
block/rect fill volume
ordinary win_text setup overhead from fragmentation

I’ll parse the full log into cohorts, then separately compare the tail section against the earlier/non-tail activity so the tig linux/ period does not get washed out by normal usage.

I parsed the full mintty.perf.43752.log with a key/value log parser. The log has 1,234 records, including 1,230 source=update records. I treated update >= 853 as the tig linux/ tail because that is where the sustained >100ms non-ASCII/self-drawn cluster begins.

mintty.perf.43752

Summary

The deeper data confirms the previous suspicion more sharply:

The slow tig period is dominated by mintty’s self-drawn box/line-art path, specifically win_text_selfdraw_boxpower, plus per-cell GDI object churn.

It is not primarily:

BitBlt
Uniscribe
ScriptStringOut
ExtTextOutW
scrolling
ASCII text

Overall profile

The 105 slow updates are only 8.5% of updates, but account for 70.3% of total update time.

The tig tail is 31.1% of updates, but 75.5% of total update time.

The culprit bucket

Across all updates:

So almost all of the pain is:

term_paint
  -> win_text
    -> selfdraw
      -> boxpower

The tail makes this even clearer:

Why it is slow

The bad path is doing self-drawn box-power rendering at near per-cell granularity.

For the 105 slow updates:

That averages per slow update to roughly:

~11,431 boxpower calls
~14,005 line ops
~17,146 CreatePen calls
~5,715 CreateBrush calls
~5,715 CreateRectRgn calls
~28,576 DeleteObject calls

This is not a text-shaping problem. It is a “draw thousands of tiny vector-ish box glyph fragments with fresh GDI resources/clips” problem.

The deeper win_text() breakdown

For the slow >100ms cohort:

There is still about 16.9s inside selfdraw not accounted for by the named resource/teardown/fill/clip timers. That is likely the actual drawing loop and GDI primitive calls themselves: line drawing, arcs, and internal per-glyph math/branching.

The important part: resource churn alone is already ~10.2s in the slow cohort:

Create*/setup: 7.07s
teardown:      3.13s

That is a very good optimization target.

What seems worth fixing

1. Stop creating/deleting GDI objects per box glyph

This is now the top target.

The current path is creating pens/brushes/regions at huge scale. Cache or reuse these within a paint/update, probably keyed by:

fg color
bg color
line width / style
cell geometry
clip rectangle shape

Even a simple per-update cache for the common pen/brush cases could remove millions of Create* / DeleteObject calls.

This should be the first real optimization.

2. Avoid per-cell clip region setup for boxpower glyphs

The slow path has:

1.2M SelectClipRgn calls
600k CreateRectRgn calls

If boxpower drawing can rely on coordinate clipping from the row/cell rectangle, or if a clip region can be reused per row/run rather than per glyph, this should help materially.

The clip timer itself is only 72ms, but that likely excludes some region object churn counted under resource/teardown.

3. Batch adjacent box-drawing cells into row/run drawing

The deeper data says the problem is not just that Unicode causes short runs. It is that self-drawn boxpower emits many primitives per cell.

A better architecture would recognize adjacent line-art cells and emit longer horizontal/vertical strokes per row or per connected segment.

Example target:

───────

should be one line/rect draw, not N glyph renders with N pens/regions/clips.

This is probably more invasive than caching GDI resources, but likely has the highest ceiling.

4. Consider using font glyphs for common box drawing instead of selfdrawing

If acceptable visually, common Unicode box drawing could go through the normal text path rather than selfdraw. The current ExtTextOutW path is comparatively cheap.

This might be configurable or limited to common box-drawing characters used by TUIs:

U+2500..U+257F box drawing
U+2580..U+259F block elements

The risk is alignment/appearance regressions. But the reward is large: ordinary ASCII text is healthy, and ordinary textout is not the bottleneck.

5. Keep scroll-copy lower in priority

Scroll-copy was a good idea from the first log, but this run says it will not fix the tig pain:

pre-tail scroll_visible_lines: 111,100
tail scroll_visible_lines:         8
slow >100ms scroll lines:          0

So scrolling optimization is still worthwhile for output-heavy workloads, but it will not address the line-art stall.

6. ASCII bidi_class() skip is still a baseline cleanup, not the main fix

There are still a lot of full-screen scans:

bidi_class_calls: 35.2M
wcw_calls:        26.9M

But the expensive tail is not dominated by those counters. This is worth doing later for general polish.

Updated priority list

1. Cache/reuse GDI pens, brushes, and regions in win_text selfdraw.

2. Avoid per-cell clip region churn for boxpower glyphs.

3. Batch adjacent box-drawing cells into longer strokes/runs.

4. Experiment with rendering common box drawing via font glyphs instead of selfdraw.

5. Then revisit scroll-copy into the back buffer.

6. Then do ASCII scan/bidi fast paths and small-update cleanup.

The fix direction is now very specific: attack win_text_selfdraw_boxpower, especially its per-cell GDI resource lifecycle and primitive emission.

I’ll inspect the self-drawn box path in the uploaded tree and prepare a small patch series focused first on removing per-glyph GDI resource churn.

I’ll stack the changes on the current patched base, verify the exact patch application point, and keep any batching or font-path experiments conservative and separate.

I’ll start with localized resource reuse in linedraw, lines, trio, rectdraw, and clip setup, preserving the deep counters for before/after validation.

I’ve confirmed the current base already includes the earlier performance commits and both instrumentation layers, so the first optimization patch can focus purely on cached GDI resources.

Built a small optimization series on top of the existing instrumentation + deep instrumentation patches.

Files:

Combined patch series
Per-commit patch zip

The series has two patches:

0001-wintext-cache-self-drawn-GDI-resources.patch
0002-wintext-avoid-dummy-text-allocation-for-self-drawn-g.patch

What it targets

This is aimed directly at the slow tig/Unicode line-art path from the deeper log: term_paint -> win_text -> win_text_selfdraw -> win_text_selfdraw_boxpower, where the log showed huge per-cell GDI churn: pens, brushes, regions, clip selection, and deletes.

mintty.perf.43752

Patch 1: cache self-drawn GDI resources

Adds a tiny selfdraw resource cache in wintext.c:

512 cached pens
256 cached brushes
1 reusable clip region

It replaces the hot selfdraw-path patterns like:

C
CreatePen(...)
CreateSolidBrush(...)
CreateRectRgn(...)
DeleteObject(...)

with cached helpers for:

boxpower common pens
boxpower heavy/round pens
line helper pens
triangle/chord brushes
rect fill brushes
boxcoded/vt52 pens
selfdraw clip region

The clip region is created once and then updated with SetRectRgn, so repeated CreateRectRgn / DeleteObject churn should mostly disappear.

Expected counter movement in the next log:

win_text_gdi_create_pen_calls       sharply down
win_text_gdi_create_brush_calls     sharply down
win_text_gdi_create_rgn_calls       near 1-ish after warmup
win_text_gdi_delete_object_calls     sharply down
win_text_selfdraw_resource_ticks_us  down
win_text_selfdraw_teardown_ticks_us  down

SelectClipRgn calls will still exist; this patch removes region allocation churn, not clipping itself.

Patch 2: avoid dummy text allocation for self-drawn glyphs

The selfdraw path was allocating a dummy text = newn(wchar, len) buffer, filling it with X, then skipping normal text output anyway. This removes that allocation/free and just keeps origtext = text.

Expected counter movement:

win_text_origtext_alloc_calls       0
win_text_origtext_alloc_chars       0
win_text_origtext_alloc_ticks_us    0
win_text_origtext_free_ticks_us     0

Checked

I verified the patch sequence on a fresh unzip with:

Bash
git apply /mnt/data/mintty-perf-instrumentation.patch
git apply /mnt/data/mintty-perf-wintext-deep-instrumentation.patch
git apply --check /mnt/data/mintty-render-fix-series.patch
git apply /mnt/data/mintty-render-fix-series.patch
git diff --check

I did not do a real Cygwin/Win32 mintty build in this container; it only has Linux gcc, not the Windows/Cygwin headers/toolchain needed for a real compile.

What I deliberately did not include yet

I did not attempt the higher-risk architectural changes yet:

batch adjacent box-drawing cells into long strokes
render box drawing via font glyphs instead of selfdraw
skip clip selection for common boxpower cases
rewrite dirty-row or scroll-copy behavior

Those could produce larger wins, but the two patches here attack the measured hot churn with a much smaller correctness surface. The next perf log should tell whether remaining time is mostly primitive drawing itself, clipping, or run fragmentation.