Now I'm moving through the other hot paths systematically—checking the Uniscribe text output functions, the paint routine, scrollback decompression, emoji matching, bidirectional text handling, character width calculations, and background fill logic. I'll evaluate each one to identify the highest-impact optimizations with minimal regression risk.

I'm going through the performance bottlenecks in the rendering pipeline, starting with the search results check and then moving through emoji matching costs, character width caching, equality comparisons, image painting, and the text output path with Uniscribe.

I see that in_results only activates during search operations. Now I'm checking whether match_emoji runs on each cell in the initial loop when emoji matching is enabled, and I need to verify if emoji support is on by default and what performance impact match_emoji has.

Looking at the match_emoji function, it calls emoji_idx to check if a character is an emoji base, which likely does a binary search across the emoji table — roughly 11 comparisons per lookup. With 16k cells per frame, that's around 180k comparisons total, which is negligible (under a millisecond). The real performance bottleneck appears to be elsewhere.

The dominant cost at 80ms on 4K is almost certainly GDI rendering — each ExtTextOutW call with ClearType at large pixel sizes, plus per-run state changes like SelectObject and SetTextColor, and the full repaint on every scroll since hardware scrolling is disabled. Drawing directly to the window DC means each text call hits the DWM-managed surface with sync overhead, though GDI does batch certain drawing functions. The big win used by other terminals is hardware-accelerated scrolling to preserve already-rendered pixels instead of re-rendering everything, which PuTTY and mintty use. I should look at why use_display_scrolling is disabled and whether enabling it could help without causing regressions.

The hardware scrolling path is too risky given the potential for regressions with sixels and other display artifacts, so I'll avoid enabling that. Now I'm examining the key rendering functions—specifically winimgs_paint which runs on every update, the text rendering paths through text_out and text_out_start, and the main paint handler.

I'm noticing a significant architectural issue: every text run triggers multiple GDI state changes—SelectObject for fonts, SetTextColor, SetBkColor, and potentially brush/pen creation for fills and underlines. On a full screen repaint with colorful output (like syntax-highlighted code or terminal utilities), this could mean thousands of runs generating tens of thousands of GDI calls. The optimization opportunity is clear: cache these state changes so we only call SelectObject when the font actually changes, and only update colors when they differ from what's already set. The tricky part is managing this safely across multiple paint paths that share the same device context, since other code like emoji rendering might change colors independently.

A safer alternative is to replace per-run brush and pen creation with DC_BRUSH and DC_PEN stock objects—just set the color once and reuse the object, which is much cheaper than creating and destroying brushes for every background fill. Though that won't work for dashed or dotted underlines, which is fine since underlines aren't the common case anyway.

I'm also checking the display speedup settings and frame-skipping logic to understand how much of the repaint cost is already being mitigated by adaptive updates during heavy output.

The real bottleneck is likely the GDI text rendering itself—on a 4K monitor at 175% scaling, a full-screen repaint could mean rendering around 19,000 cells, which should take 5–20ms with standard ExtTextOutW. But if Uniscribe is enabled by default for script analysis, that per-run overhead could be significantly slower, so I need to check what the default font_render setting is and how text_out handles Uniscribe processing.

The default font rendering mode uses Uniscribe, which means every text run triggers a full itemization, shaping, and glyph generation cycle through ScriptStringAnalyse—an expensive operation. For a typical full-screen repaint with syntax highlighting across multiple runs, this results in hundreds of these costly calls.

The optimization would be to skip Uniscribe for pure ASCII runs and use ExtTextOutW directly, which PuTTY does and mintty once had but removed because Uniscribe applies ligatures from fonts like Fira Code. The solution is to gate this optimization on the ligatures config setting—if ligatures are disabled, ASCII runs don't need Uniscribe's shaping engine, but if they're enabled, Uniscribe is necessary to apply OpenType features that plain ExtTextOutW can't handle.

The issue is that with cfg.ligatures defaulting to 1, Uniscribe applies ligature shaping by default, so ASCII text gets processed through the full shaping pipeline. To make the ASCII fast path work without regressions, I'd need to gate it on cfg.ligatures == 0, which means it only benefits users who explicitly disable ligatures. It's still a valid optimization for that use case and worth documenting, but it won't help the default configuration.

Now I'm profiling the full rendering pipeline for the worst case—a full screen of changed text at 4K resolution with scrolling. The three main bottlenecks are the term_paint loops over cells (1–3ms), fetch_line decompression when scrolling through scrollback history (5–15ms per frame), and the Uniscribe analysis per text run in win_text (likely 25–100ms per frame, which is probably where most of the 80ms overhead comes from). Even with plain output, there's still significant cost from running ScriptStringAnalyse on each dirty line.

The biggest win would be reducing the per-run cost of text output in the common case. I'm exploring whether we can use a fast path for ASCII when the font doesn't have ligatures or contextual alternates that would affect rendering. The challenge is detecting this cheaply—GetFontLanguageInfo returns flags about the font's capabilities, but it's really about complex script support rather than specific OpenType features like liga or calt. Fira Code's programming ligatures actually use contextual alternates, which Uniscribe applies by default for Latin script, so I need to figure out how to detect whether the current font has these features enabled.

I'm also considering safer alternatives: caching results where possible, reducing redundant work during idle periods (which seems fine already since repaints only happen on schedule), batching GDI state changes to save a few microseconds per call, and looking at whether the dirty region tracking at the displines level is being used effectively to avoid painting the entire terminal every frame.

There's also a big optimization for 4K screens around the SSA_FALLBACK flag, and I'm thinking about how to handle space-only runs — they're extremely common when scrolling code with indentation, maybe 50% of cells. If a run contains only spaces and the font has no underline or strikeout attributes, I could skip Uniscribe entirely and just use a fast rectangle fill with ExtTextOutW, but I need to be careful because spaces with underline fonts still render the underline through the font metrics.

Actually, there's a simpler angle: ScriptStringAnalyse is really only needed when text benefits from complex shaping. For ASCII-only runs in a fixed-pitch font, the only difference would be contextual ligatures like in Fira Code. I could gate this on the ligatures config setting — if ligatures are disabled, skip Uniscribe for ASCII runs entirely, which would actually fix the current behavior where Ligatures=0 still seems to apply ligatures through Uniscribe's neutral item merging.

The docs already provide a way to disable ligatures globally through FontRender settings, so adding an unconditional ASCII bypass would break documented behavior. I need to dig into where that 80ms is actually being spent—looking at the paint path, background filling, decompression costs, and whether there are any redundant operations I can optimize.

My main hypothesis is that on 4K displays, the bottleneck is ScriptStringAnalyse being called repeatedly per run during scrolling, where the entire screen becomes dirty and every line gets re-analyzed. I'm exploring whether caching ScriptStringAnalyse results keyed by font, text content, and length could help—terminal output is repetitive enough that during scrolling the same strings move up rows and would hit the cache frequently. The tricky part is managing the cache safely: SSA is tied to the device context and selected font at analysis time, so I'd need to flush the cache on font changes and handle DPI changes carefully to avoid regressions.

I'm also considering simpler wins: skipping Uniscribe entirely for runs that are only spaces, since blank space dominates terminal rendering and ExtTextOutW with ETO_OPAQUE for background fill is cheaper than full script analysis. I'd restrict this to the main rendering phase and keep it conservative to avoid edge cases where a font legitimately lacks ASCII glyphs.

Beyond that, there's the possibility of batching optimizations with GdiSetBatchLimit to reduce kernel transitions, though the gains there depend on how much overhead Uniscribe's internal ExtTextOutW calls currently incur.

More promising is eliminating redundant GDI object creation: instead of CreateSolidBrush and DeleteObject for each background clear, I could use SetDCBrushColor with the stock DC_BRUSH object, and similarly swap CreatePen for SetDCPenColor when drawing solid underlines. The brush optimization matters more since background clearing happens frequently, while underlines are less common.

For caching SelectObject and color state across multiple win_text calls, the challenge is that win_text itself makes multiple SetTextColor calls mid-run for shadows, bloom effects, and combining characters—so any cache wrapper would need to intercept every color change to stay accurate, which introduces significant regression risk for minimal gain. A narrower approach might be caching only the font selection when the same font is already active in the DC, since SelectObject is relatively cheap in that case anyway.

I should verify whether SelectObject actually shortcuts when given the same handle, and check where SelectObject and SetTextColor are actually called throughout wintext.c—particularly whether win_char_width uses the same global dc or a separate compatible DC. There are also other potential bottlenecks worth examining: scrollback decompression happens on every frame update (though updates only trigger when something changes), and winimgs_paint runs every do_update even if there are no images to draw.

I'm reconsidering the scope here—caching across all SelectObject sites would get unwieldy, so I'm deprioritizing that broader idea and focusing instead on the space-run bypass plus some targeted micro-optimizations. The best candidates by risk-to-reward are the Uniscribe bypass for blank regions, which should help without regression risk, and using DC_BRUSH and DC_PEN for the clear and solid pen operations.

Now I need to ground this in actual performance data. I can't easily benchmark the Windows GDI calls on Linux, but I should search the mintty repo's wiki and issue tracker for known performance bottlenecks—looking through the changelog and GitHub issues for reports of slowness on 4K displays or general rendering lag. Before diving into patches, let me trace through a few more critical code paths like the WM_PAINT handler, the background fill logic, and the character width caching to understand where the real hotspots are.

I noticed that winimgs_paint is doing GetDC/GetClientRect/IntersectClipRect/ReleaseDC calls even when there are no images to render, which is a minor inefficiency. Next I want to check whether win_char_width caches its results, then examine apply_attr_colour and fill_background, and finally look into what performance issues have been reported for this code online.

I'm noticing that win_char_width isn't being cached, so every call triggers expensive operations like getting a device context, selecting objects, and querying the font through kernel calls—and in some cases it actually renders the glyph to measure it. I need to trace where this function gets called during term_paint, particularly in that first loop when characters don't match what's already displayed.

Looking at the condition more carefully: it's checking if the character is narrow (not marked as wide), char_narrowing is below 100 (which appears to be the default at 75), and win_char_width returns 2. This means for every changed non-ASCII narrow character, we're hitting that expensive GetDC + SelectObject + GetCharWidth32W path, and possibly the render-measure fallback for characters outside the BMP or when GetCharWidth fails. I need to see where act_char_width actually gets invoked—it looks like for BMP characters that GetCharWidth32W reports as narrow, the code falls through to act_char_width, which might be doing the actual glyph rendering measurement.

I found something significant: win_char_width gets called repeatedly from the term_paint loop for every changed non-ASCII or non-wide character, and it's doing expensive kernel operations each time—getting a device context, selecting an object, and calling GetCharWidth32W to measure characters.

But here's the real problem: for characters in certain "measure" ranges, it calls act_char_width() which is catastrophically expensive—it creates a compatible DC and bitmap, renders the glyph through Uniscribe/ExtTextOut, reads back the entire 2-cell bitmap with GetDIBits, and scans pixels to determine width. That's easily 100 microseconds to a millisecond per call with no caching at all. During scrolling with Unicode-heavy content, every changed cell triggers this, meaning hundreds or thousands of calls per frame—rendering becomes glacially slow. The early returns for box drawing and other special ranges happen after the initial GetCharWidth32W call for BMP characters, so they don't help much, and I need to trace through the exact order of these checks to understand where the bottleneck really is.

There's a cache for the render-measure path, but it uses a linear scan to look up entries—so with CJK-heavy content where the cache can balloon to thousands of entries, each cell change triggers an O(n) lookup. Scrolling through a screen of CJK characters means tens of millions of comparisons per frame, which is likely a significant bottleneck.

The non-measure path for BMP letters like Cyrillic, Greek, and accented Latin isn't cached at all—every changed cell does a full GetDC, SelectObject, GetCharWidth32W, and ReleaseDC cycle. For a screenful of Russian text scrolling, that's 19k cells times several microseconds each, easily hitting 40–120ms. This is almost certainly the user's 80ms problem. The fix is to cache win_char_width results across all paths using an O(1) structure, invalidated whenever fonts change, hooking into the existing cpcache invalidation mechanism that already handles font updates.

The invalidation point for the new width cache should align with win_init_fontfamily, which gets triggered whenever fonts, DPI, or zoom settings change. Now I'm checking what the performance community has documented about mintty's bottlenecks to confirm that win_char_width and Uniscribe are indeed the main culprits, and whether there have been any improvements since version 3.8.3.

I notice the version 3.8.3 is from June 2026, which is actually after my knowledge cutoff, but the archive itself is the authoritative source. The changelog mentions they've already optimized glyph width checking for symbol ranges and added caching for ambiguous character widths—both addressing performance issues similar to what I'm investigating. I should search for documented mintty performance problems to focus on the actual bottlenecks rather than guessing.

I'm noticing a pattern across these performance issues—wttr.in and Neomutt both rely heavily on Unicode symbols and ANSI colors, which aligns with the character width calculation problem. I should dig into the existing bug reports and search the mintty codebase for references to win_char_width and GetCharWidth to understand how the maintainer diagnosed this.

I should look into the specific performance issues mintty has documented—particularly around character width calculations and the related GitHub issues that mention optimization work. Let me search for those known hotspots and any high-DPI rendering problems that might explain the slowdown.

The maintainer's own notes confirm that per-character rendering carries a substantial performance cost, and the changelog shows repeated attempts to optimize width-detection overhead—which aligns with where I'm focusing my improvements. I'm now checking the second potential bottleneck around the default configuration, specifically whether apply_attr_colour and win_get_colour calls are actually expensive per run, or if the real issue lies in the Uniscribe ScriptStringAnalyse operation.

I'm also noticing that during selection, win_get_colour(SEL_COLOUR_I) gets called per selected cell, which directly matches the wsltty#67 report about lag when selecting curl output with the mouse. For the resize lag issue, I'm tracing through how term_invalidate triggers a full repaint on WM_SIZE, and with Unicode symbols like moon phases and box-drawing characters, the win_char_width measurement path becomes a bottleneck—especially the linear scan through the character cache, which can hit millions of comparisons when dealing with large symbol sets, though it stays manageable for smaller alphabets. The uncached GetCharWidth32W path for letters like Cyrillic, Greek, and accented Latin characters is where the real slowdown likely occurs.

I'm realizing there's a critical ordering issue in the CJK width-checking logic: for wide characters in ambiguous-width locales, win_char_width (which calls GetDC and GetCharWidth32W) is being evaluated before the cheap is_ambigwide table lookup, so every changed CJK cell pays the expensive system call cost even when is_ambigwide would return false and short-circuit the whole condition. Swapping the evaluation order is safe since both are pure predicates and the caching side effects are invisible to the final result—this would skip the expensive call entirely for genuinely wide CJK text.

For the narrow branch, there's no cheap predicate to hoist, so the real fix is memoizing win_char_width itself. I'm designing a hash table cache keyed on character, font index, and font4 style—either per-family (4KB per style, ~192KB total) or a single global 16384-entry table (64KB). The cache sits in front of the existing cpcache logic, which remains authoritative for glyph presence checks; on a cache miss, I run the existing path and store the width result in the new hash.

For invalidation, font changes and cell dimension updates all funnel through win_init_fontfamily, where I'll flush the entire hash. Since mintty's GUI is single-threaded, there's no concurrency concern. I need to check how font4 uses the attr bits to define the exact cache key. The second optimization is hoisting the is_ambigwide check before win_char_width in term_paint, and the third is bypassing Uniscribe for space runs in win_text. The memoization makes GetDC misses rare enough that skipping that optimization keeps the diff manageable. For DC_BRUSH, I'll include it in clear_run since it's a per-run cost, but skip win_paint where it's negligible. Now checking the emoji matching — emoji_idx does a binary search, which is fine, but check_emoji might be doing filesystem access calls to verify emoji image existence; I need to see if that's cached or if it's only triggered on actual matches. The wcschr calls for emoji sequences are guarded and rare, so those are safe. The dirty_run computation with termchars_equal_override is cheap per cell, and in the third loop, bidi_class does a binary search over ranges (roughly 9 iterations) plus is_comcom checks — across 19k cells per frame that's still sub-millisecond, so acceptable.

For the default Latin-text case, term_paint does call win_char_width even for ASCII, but that function returns early for ASCII before hitting GetDC, so it's just a function call overhead. The real cost comes from non-ASCII changed cells like box-drawing characters in tmux or htop borders — those trigger GetDC, SelectObject, GetCharWidth32W, and ReleaseDC, plus potentially a render-measure path. Box drawing characters typically report as width-2 after GetCharWidth, so they do incur the full GDI cost.

Even though box-drawing gets self-drawn with TATTR_ZOOMFULL, the narrowing condition still evaluates win_char_width before checking that flag, so the GDI calls happen every frame for every changed box character. A full-screen tmux border redraw could mean hundreds of these calls per frame. Memoization would fix this uniformly across all character types.

Now I need to look at the font4 structure to define the cache key bits properly, then trace through emoji_idx and check_emoji.

The emoji caching mechanism handles per-emoji filename resolution correctly. Now I need to verify my main hypothesis holds up at 175% scaling with realistic content, then cross-reference how win_char_width is being used throughout the codebase—particularly in functions like win_combine and charnames—to ensure the design is consistent.

The win_char_width function is also being called from the output path in termout.c around line 1622, likely for handling Powerline and box-drawing characters as they're written to the terminal. Memoizing this function would speed up the raw throughput on the output side as well. The results depend on the character, font index, bold mode when using bold fonts, italic styling, and the current font — the same parameters that font4 tracks.

I'm designing a cache key that packs the character (21 bits for Unicode up to 0x10FFFF), the clamped font index (4 bits for 0-10), and the font4 index (2 bits) into a 27-bit uint32 key, storing the character width as the value. The key is deterministic based on the requested bold and italic bits, which get flushed whenever fonts change. The measurement itself uses the styled font selected via font4, so keying on those attributes captures the full dependency. Cache invalidation happens when fonts are reinitialized — either through family changes in win_init_fontfamily, DPI/zoom adjustments, or mode flips like underline or bold mode.

These edge cases are gated to specific ranges rather than the common path. Now I'm reviewing the term_paint ambiguity branch to verify the ordering of the condition checks around line 3716, specifically looking at whether testing is_ambigwide earlier in the sequence would be more efficient.

I'm checking that is_ambigwide is a pure lookup with no side effects, and confirming that win_char_width only affects cache population which is safe under short-circuit evaluation. For the space-run bypass optimization, I'm planning to add a scan in win_text right after the use_uniscribe flag is set — if all characters in the text run are spaces, I'll disable Uniscribe since it's unnecessary overhead. The scan is cheap for typical column widths, and the boxpower/boxcoded/dectcs paths that replace text with placeholders won't interfere since they skip drawing anyway. Spaces exist in every font so there's no font fallback concern. I'm also checking where else text_out_start gets called to ensure this optimization doesn't create inconsistencies — it appears to be isolated to win_text aside from the static flag set in act_char_width.

The cpcache linear scan can stay as-is since my front-end hash cache will shadow it anyway, preventing most misses from reaching the list. I'm also considering whether hoisting win_get_colour(SEL_COLOUR_I) out of the per-cell selected branch in term_paint's first loop would be a worthwhile micro-optimization.

win_get_colour is straightforward enough. Now I'm checking whether is_ambigwide is just a table lookup and looking into how the character width functions are structured in mcwidth.c.

I'm planning a series of patches to optimize character width handling. First, I'll implement is_ambigwide using two binary searches for speed and safety. Then I'll memoize win_char_width with a compact hash table that encodes the character, font index, and font4 index into a single 27-bit key, using zero as a sentinel for empty slots.

For the cache implementation, I'm using a fixed 8192-entry table with linear probing and simple eviction on overflow — since the realistic character population per session is small and we flush on font changes, this is plenty. The tricky part is handling the existing debug macro that redefines win_char_width, so I'll rename the core logic to win_char_width_raw and wrap it with a cached version that handles the multiple return points cleanly.

Now I'm looking at several smaller optimizations: hoisting the ambiguous-width and Geometric Shapes checks before the win_char_width call in term_paint to avoid the function call when possible, skipping Uniscribe shaping entirely for runs that are all spaces, and switching to DC_BRUSH with SetDCBrushColor in clear_run to avoid repeated brush creation and deletion. I need to verify the Windows version requirements — DC_BRUSH is available since Win2k so that's safe. For winimgs_paint, there's a potential early-out when there are no images, though the function also handles tempfile cleanup and stale image freeing, so the overhead is minimal even if we skip the main loop.

I'm also reconsidering SetScrollInfo in do_update — it's called every frame with usually-identical values, and caching the last SCROLLINFO to skip redundant calls could save scrollbar redraws. The risk is that external state changes (window resize, config toggles) might invalidate the cache, so I'd need to reset it in win_adapt_term_size and config change handlers, which spreads the logic. Probably not worth the complexity.

Now for the real bottleneck: 80ms on plain ASCII colored text with no Unicode. win_char_width doesn't even run (ASCII early-out), so the cost is Uniscribe per run plus GDI rasterization at 4K. The space-run bypass helps a bit, and frame skipping already exists via DisplaySpeedup. Let me trace through the third loop's dirty-run logic again — dirty_run starts as (line->lattr != displine->lattr), then out_text is called for each changed run. Unchanged lines only pay the CPU loop cost, which is fine.

But at 175% scaling on a huge display, the cell count explodes — a 9pt font at 175% becomes roughly 21px wide, so 3840 pixels wide gives ~295 columns and 2160 pixels tall gives ~72 rows, totaling around 21k cells. During heavy scrolling output like ls -R, every line is dirty, and with an average of 4 runs per line, that's ~290 ScriptStringAnalyse+Out+Free calls per frame, each shaping ~74 characters, and the cost scales with the character count.

Uniscribe throughput is maybe 5-20M chars/sec, so 21k chars per frame is only 1-4ms. GDI text blitting at 500M-2G pixels/sec means 8.3M pixels takes 4-16ms. Full-screen text repaint should be 10-25ms, but the user sees 80ms — the gap points to either heavy non-ASCII content triggering win_char_width, decompression lag from scrollback, or run explosion from syntax coloring (hundreds of tiny runs, each with 50-100µs fixed overhead). For the run explosion case, the real issue is that mintty doesn't cache the SCRIPT_CACHE per font — it lets ScriptStringAnalyse manage it internally and frees it each time, forcing glyph lookups to repeat. Using the lower-level Uniscribe API with a persistent SCRIPT_CACHE would cut that per-run overhead dramatically.

My patches target the non-ASCII case hard and partially address run explosion with blank run optimization, but a full renderer rewrite to use persistent caching is too invasive. I should also check apply_attr_colour to make sure it's not doing something expensive per run, and verify that colour_dist and brighten only run for cursor cells. One more thing — show_curchar_info calls get_char_info every frame for the character info feature; I need to check if that's doing a charnames lookup that could be adding overhead.

I'm satisfied with the patch logic—the early-exit conditions for the character info feature and the bit manipulation in the color application both check out. Now I need to verify the build setup to ensure my code compiles correctly with their flags and matches their use of GNU C extensions and C11 standard.

I'm noticing that wintext.c is deliberately compiled without optimizations—the build explicitly uses -O0 to override the default -O2—because enabling optimization causes a mysterious delay issue in the text rendering. This means the most performance-critical file in the GDI text renderer is running unoptimized, which is a significant performance hit, though fixing it risks reintroducing that elusive bug.

The build also enforces strict compilation flags: -std=gnu99, -Wall -Wextra -Werror for warning-free code, and -include std.h to provide utility macros like uint, uchar, and when.

Now I'm creating patches using git format-patch so the user can apply them cleanly. The first patch will add memoization to win_char_width in wintext.c, and I need to examine the exact function layout around the debug scaffolding to position my changes correctly.

I'll examine the debug scaffolding around win_char_width to ensure the patch integrates cleanly, then set up a git repo for the patch series.

I'm noticing I computed wcw_slot twice in the wcw_store function, which is inefficient, and the bitwise AND operation is actually redundant since wcw_slot already constrains the result to the proper range. Let me refactor this to call it just once.

For the probing logic in wcw_lookup and wcw_store where I'm computing (slot + i) & (WCW_CACHE_SIZE - 1), the mask is necessary there because slot is less than SIZE but adding the probe offset i can exceed the cache size, so the wrapping is correct to keep. I should also reorganize the store function to follow my convention of placing helper functions first.

I'm spotting an issue with how the debug macro wrapper interacts with the preprocessor. The #ifdef debug_win_char_width block comes before the uncached function body, and the #define win_char_width xwin_char_width directive is renaming all subsequent win_char_width tokens throughout the file — including the wrapper function's own definition name and references in the uncached function, which is causing the macro substitution to cascade in unexpected ways.

Let me verify the identifier handling: win_char_width_uncached is a distinct identifier so it won't be affected by the macro replacement, and the recursive calls within the uncached body's debug blocks will correctly invoke the cached wrapper. With debug mode off, the wrapper compiles as the extern win_char_width that matches the header declaration. The static win_char_width_uncached is defined before the wrapper calls it, so no forward declaration is needed, and there are no unused-function warnings since everything is being called. Ready to commit this patch.

I'm checking the order of operations in the win_text function to understand when use_uniscribe gets assigned relative to the origtext replacement. Looking at the sequence, the original text gets saved and replaced around line 3415, then there's the box painting section, and then the Uniscribe handling assignment comes after that.

I'm thinking through how to verify this without Windows headers available—I can unit-test the cache logic independently on Linux since that's the core new algorithmic piece, and I can do a syntax check by extracting the cache block with stub types to at least confirm it compiles as C code.

I also need to verify the bit-packing logic in the key generation: checking that xchar is indeed a uint, confirming the operator precedence is correct (bitshift binds tighter than bitwise-or), and making sure there are no unexpected compiler warnings about signed/unsigned comparisons or C99 features. Finally, I should scan the diff one more time and check whether wcw_* symbols already exist elsewhere in the codebase.

I'll unit-test the new cache logic and lint it under the project's warning flags since I can't verify against Windows headers on this Linux system.

The cache tests are all passing and compiling cleanly with strict warnings enabled, which is solid. The eviction test shows good memory utilization at full capacity, and the 4000-entry working set confirms that probe distances are reasonable at this load factor. Now I'm doing a broader syntax check across the modified wintext.c and term.c files to catch any issues, though some tools like gcc -fsyntax-only have their own constraints.

Instead of trying to work around the Windows header dependencies, I'm taking a more practical approach: carefully re-reading the final diffs from each patch and verifying the logic manually. For the debug_win_char_width path specifically, I'm tracing through the macro renaming to confirm the wrapper definition aligns correctly with the forward declarations and extern declarations — the macro redirects to xwin_char_width when debug is enabled, and uses plain names when disabled. I'm also double-checking patch 3 to ensure that the text buffer isn't being modified unexpectedly in the combining character branch, and that the text_out calls with subsets are handling the uniscribe path correctly.

Now I'm examining a potential edge case with combining character runs: can a combining run consist entirely of spaces? The combining flag is set when a cell has combining characters appended, so the text would include both a base character and combining diacritics. Even if the base is a space, the combining codepoint itself (like U+0301) isn't a space, so the blank check should pass. There's also the zero-width space (U+200B) used for bidi isolate marks, which also isn't a regular space. The clearpad calls that fill padding with single spaces should bypass Uniscribe and produce identical results.

I'm also checking for negative interference with win_check_glyphs placeholder entries — those use width=0 to indicate "glyph presence checked but width not yet measured." My front cache only stores final results, never the 0-placeholders, but there's a subtle issue: if GetCharWidth32W actually fails and returns 0 as a real result, my cache will memoize that 0, and subsequent calls will return the cached 0 without retrying.

To be safe and avoid regressing behavior, I should add a guard that doesn't cache 0 results — treating them as uncacheable failures so the behavior matches the original retry-per-call approach. I'm also verifying that font creation through font4 is deterministic and that FontSubst substitutions don't affect per-findex measurements. I need to amend the first patch with this no-cache-on-zero guard, though that means rebasing the later commits.

I found that win_char_width can return 0 on GDI failures, and this shouldn't be memoized like the original code does. I'll fix that and include it in the first commit.

I'm doing a final pass through the wintext.c diff to make sure everything looks solid.

I spotted a structural issue during review—my cache block got wedged between a doc comment and the function it describes, splitting documentation from its target. The comment block at lines 633-635 actually belongs to win_init_fontfamily, not check_font, so I need to relocate my insertion above that comment to keep things properly organized. With debug mode on, the wrapper's comment about win_char_width works fine. I need to fix the placement issue by editing commit a2fe558 and re-squashing it, starting by locating where that doc comment begins.

I found the cache block was placed between a function's doc comment and its definition. I'll move it to the correct location.

I'm doing a final sanity check on the modified wintext.c file to ensure structural integrity — checking that braces and parentheses are balanced. Since the extracted block already compiled successfully, I can verify that my additions are properly balanced and haven't introduced any syntax errors.

Now I need to generate the patch series using format-patch and place it in the outputs directory, then write comprehensive build instructions. I should also provide the user with the analysis I promised: breaking down where the 80ms performance gain comes from, what each patch accomplishes, and how to build in Cygwin. I'll flag that wintext.c is deliberately compiled with -O0 due to a historical "mysterious delay" note and advise against changing that blindly. I should document the existing runtime knobs that matter at 4K resolution — DisplaySpeedup, FontRender=textout for disabling Uniscribe/ligatures, BoxDrawing, and CharNarrowing=100 — and suggest concrete benchmarking approaches like timing seq -f 'yes %g' 200000 and testing with Unicode-heavy files to see the first patch's effect. Finally, I'll outline a regression testing checklist covering font dialog changes, zoom operations, DPI switching between monitors for cache flush correctness, and ambiguous width handling. I'll focus on delivering just the four patch files without the test harness to keep things streamlined.

I should use plain patch -p1 instead of git apply --directory=. to validate the patch on a pristine tree, since that command fails when the directory isn't a git repo and also works for users who don't have git installed.

I've confirmed that the upstream version doesn't have a Ligatures=0 fast path either, so this patch introduces genuinely new functionality. Now I'm writing patch 5, which will include both code and documentation changes to handle the ligature disabling logic in the text rendering function.

Writing patch code... DEL (0x7F) is correctly excluded since it's a control character that shouldn't appear in cells anyway. The findex check works because at this point it's either 0 (primary font or self-drawn remaps) or would already have use_uniscribe set to false for RTL cases. For the documentation, I need to clarify that ligatures can't be disabled in general except through Ligatures=0 or FontRender=textout, then add a note explaining what happens when Ligatures=0 with ASCII text chunks.

Upstream doesn't support disabling ligatures since they're handled by Windows, but the current code treats Ligatures=0 and =1 identically—I'll fix that by making Ligatures=0 actually disable them while keeping the default behavior unchanged.

I'm seeing how DisplaySpeedup controls the refresh rate during heavy output — when it's enabled, mintty skips up to N 16ms intervals, so during something like find ~/, repaints happen roughly every 96ms plus the paint duration itself, which bottlenecks the frame rate to around 8–10 fps since each paint operation sweeps the entire window top-to-bottom. Setting DisplaySpeedup to 0 disables this skipping behavior entirely.

Now I need to check whether double buffering is feasible by examining several components: the emoji display DC usage, how winimgs_paint handles drawing calls and suppression, whether the window style includes WS_CLIPCHILDREN, how the transparency mechanism works, and tek_paint's DC usage.

I'm realizing the core issue: emojis bypass the global device context entirely by getting their own handle and drawing directly to the window, so a simple buffer-and-blit approach would overwrite them when the buffered text gets composited back. The emoji rendering happens independently of the text pipeline, which means I need a different strategy than just redirecting the main drawing context.

I'm considering two paths forward. One is to defer emoji drawing until after the buffer blit, but that requires restructuring when emojis get rendered during the paint cycle. The other is to make emoji drawing use the global device context instead of acquiring its own — this would naturally integrate emojis into the buffered rendering, but I need to verify that win_emoji_show is only called in contexts where the global context is valid, and I'm concerned about coordinate transforms that might be applied to the global context during updates that wouldn't apply to a direct GetDC call. The safest approach is to skip buffering entirely when sixels are present, since that's a rare edge case with full-speed find output. For emojis, I need to redirect them to draw on the provided DC and verify how the horizontal clipping compensation works in the code — I should check the horclip usage in winimg.c and confirm the global dc is properly declared extern in winpriv.h.

Looking at how the GDI+ emoji rendering works, it creates its own device context directly from the window rather than using the global one, which means it bypasses the normal buffering and draws straight to the window surface. It then manually adjusts the column positioning to account for horizontal clipping, and sets up its own coordinate transformation for rendering.

The core problem is that if I redirect emoji drawing to use the global buffered device context, the horizontal clipping transform gets applied twice—once in the emoji code's manual compensation and again from the global context's world transform. Plus, the emoji code replaces the entire world transform rather than composing with it, which would destroy the existing horizontal offset that's already set up on the buffer.

The cleaner approach might be to apply the horizontal clipping offset at the blit stage instead of during drawing—render everything into the buffer using untransformed terminal coordinates, then shift the entire buffer horizontally when copying it to the window. This way the emoji rendering doesn't need to know about clipping at all.

But that requires the buffer to be wide enough to hold the full logical terminal width when horizontal scrolling is active, which defeats the purpose of buffering to the client window size. So the pragmatic solution is to just disable buffering entirely when horizontal scrolling is active—it's marked as experimental anyway. That leaves emoji still drawing directly to the window, which is fine since the buffering bypass conditions already handle the edge cases.

The remaining question is whether to add another bypass condition for when emoji are present in a frame, or to redirect emoji drawing through a helper function that returns either the buffer DC or the window DC depending on whether buffering is active.

Redirecting emoji into the buffer is doable but requires careful handling: the emoji code applies a world transform for italic slant, and if it's drawing to a shared buffer DC instead of its own DC, it needs to restore that transform afterward to avoid corrupting subsequent text runs. That's a moderate change to the emoji drawing code, but it's cleaner than tracking whether emoji were drawn and trying to handle them after the fact. The frame rendering sequence keeps images on top since they're drawn after the blit, but when scrolling moves images and other cells in their rows get dirtied, the buffer holds blanks from the last time those image cells were marked dirty—so blitting those rows erases the image unless something forces a redraw. That means I need to keep the bypass that skips buffering when images exist. Now I'm thinking about tracking which spans get blitted so I can hook into win_text to record the min/max dirty rows. The overhang from clearpad and ldisp2 boxes extends into the padding region, which complicates the blit strategy. If I buffer the padding area, I'd need to initialize it with the padding background color and handle rvideo color changes, but that gets messy since WM_PAINT repaints the window padding independently. The cleaner approach is to restrict the blit to just the text area and let the window padding stay pristine from WM_PAINT—the overhang pixels drawn into the buffer won't appear in the window padding anyway, so there's nothing to clear there, which is actually consistent with the desired rendering.

I'll accept that italic glyphs might clip up to Padding pixels at the text-area edge under buffering (invisible with Padding=1, minor truncation with larger values), and I'll make this whole buffering system optional via a DisplayBuffering bool flag, defaulting it on. Before blitting, I need to exclude the search bar region to avoid overwriting it, and I should audit the GetDC call sites across the paint graph to ensure nothing else is drawing directly during term_paint that would bypass the buffer.

The real trap is keeping the buffer and displines cache in sync — if WM_PAINT runs unbuffered while do_update expects buffered output, the buffer goes stale and subsequent blits corrupt the window. So both paths (do_update and win_paint) must route through the buffer around term_paint, then blit atomically. For the bypass cases (tek, images, horclip), when term_paint draws direct and the buffer stales, I need to detect the transition back to buffering and force a full invalidation so term_paint repaints everything into the buffer before the next blit — I'll track this with a buffer_stale flag that triggers a full term_invalidate on the next buffered frame.

Buffer recreation on resize gets the same treatment (mark as stale), and ClearType renders fine on the memory DC since it's compatible with the window format. The padding fill in win_paint stays direct to the window (excluded from the buffer region), and multi-monitor DPI changes or font zoom that alter cell dimensions will trigger the full repaint cycle through WM_PAINT and the existing term_invalidate logic. Keying the buffer on client pixel size plus marking it stale on recreation should close the loop, and the blit uses matching coordinates since the buffer is sized to the client area.

For the search bar, I'm realizing the better approach is to paint the full buffer without clipping (so it always has complete content), then apply the exclusion only to the blit operation on the window DC — that way when the search bar closes and the exclusion is removed, the next blit immediately shows the correct content without stale pixels.

Now I'm settling on the option name DisplayBuffering as a boolean (defaulting to true so the fix works out of the box), with the understanding that all the bypass conditions will dynamically revert to the old behavior if needed. I also need to be careful about how the global DC is used throughout do_update — it's passed to win_paint_exclude_search, then used for term_paint and other steps, so I'll need to restructure this minimally to keep the buffer separate from the window DC during the actual painting.

For the implementation, I'm setting up static storage for the buffer DC, bitmap, and tracking whether it's stale or currently engaged. I'll create helper functions to begin and end buffered painting, plus an accessor for the paint DC that returns the buffer when active or the window DC otherwise. For the emoji code, I need to make sure it properly handles the shared DC case — restoring the transform and graphics mode after drawing, whether it's using the buffer or its own DC, and being careful about GDI+ state changes.

Now I'm thinking through the clipping behavior: the global buffer DC won't have transforms or the text-area clipping, which actually improves isolation. The shared DC's clip state when emoji_show runs should be clean since win_text either leaves no clip or clears it. For the blit operation, I need to figure out the source and destination coordinates — whether to include padding and handle overhang regions properly.

I'm settling on blitting just the glyph-reachable text rectangle (from PADDING to PADDING+colscw horizontally, and from OFFSET+PADDING to OFFSET+PADDING+allrowsch vertically), which means accepting that italic overhang might clip at the padding boundary — a negligible visual difference. I'll document this trade-off in the commit message.

For buffer initialization, I'll fill the entire buffer with the background color on creation so any never-painted cells within the text rect are safe, even though a full invalidate should paint everything before the first blit anyway.

Now I'm restructuring do_update to handle horizontal scrolling...

Refactoring paint flow... Now I'm checking where the global dc gets assigned — only in do_update and win_paint, so nothing else should be using it while it's pointing at the buffer. I need to verify that term_paint's external callers are limited to term.c and that the search bar handles its own painting independently. For the config, I'm adding a display_buffering boolean field near display_speedup, setting it to true by default, and adding the corresponding option entry and documentation. Then for patch 7, I'm reconsidering whether to force ASCII/non-ASCII run breaks — without it, the only difference from current behavior is that runs like "1.é" would merge and be shaped together by Uniscribe instead of being split, which might actually be desirable. Adding the tracking logic... I need to verify that config.h is included in term.c to access the FR_TEXTOUT enum, and I'm checking that the RTL break logic still fires correctly since RTL classes are non-ASCII anyway. The chunk boundaries also feed into ligature support and SEA character handling, which work orthogonally. The DATTR_STARTRUN bookkeeping adapts automatically when run boundaries shift, making the invalidation conservative and safe. This chunking strategy should reduce ExtTextOut calls at digit-letter and punctuation boundaries, cutting down on per-run overhead costs that dominate the timing budget. I'm also considering a pacing tweak where the timer cadence during saturated output creates an effective 8fps refresh, which might benefit from DisplaySpeed adjustments.

Now I need to systematically verify implementation details across the codebase — checking OPT_BOOL declarations, global device context assignments, all callers of win_text and winimgs_paint, the full win_emoji_show function including transform restoration and DC management, tek_paint's DC usage, config.h struct layout, win_paint_exclude_search logic, term_invalidate signatures, buffer prefill colors, and how WM_PAINT interacts with win_adapt_term_size.

I've identified two issues: DisplaySpeedup caps refresh rate by design (around 8–10 fps), and the line-by-line painting causes visible mid-paint artifacts because DWM composes while the update is happening. I'll trace the paint path to add double buffering without breaking special rendering.

I've confirmed the key details about the drawing context: there's a global static DC in wintext.c that gets initialized in do_update and win_paint via BeginPaint, and all term_paint operations draw to it, while Tek mode uses its own separate GetDC call. The win_paint_exclude_search function applies clipping to the DC, and win_text is only called from term.c.

Now I need to check whether win_emoji_show properly restores the world transform after drawing, trace through its exact GetDC/ReleaseDC pairs, and also examine the GDI+ calls in winimg.c around lines 426 and 595 that handle image drawing, plus the blit operations at lines 1041 and 1065. Let me work through the full win_emoji_show function from line 1113 onward.

The win_emoji_show function already handles world transform restoration cleanly with a single GetDC/ReleaseDC pair, so redirecting it to use a shared paint DC is straightforward—I just need to replace the GetDC call with an accessor function and match it with a corresponding release. There's one edge case to watch: the column calculation col = PADDING + x0*cell_width - horclip() behaves differently depending on whether buffering is active, since we skip the calculation when horclip() isn't zero under buffering.

When buffered, the shared DC is the buffer with no transform applied (we bypass when horclip() is non-zero), and win_emoji_show subtracts horclip()=0, which keeps everything consistent. The graphics mode issue is also manageable—win_emoji_show sets GM_ADVANCED for italic rendering but never restores it, leaving the mode on the shared DC. Since GM_ADVANCED only affects certain semantics like arc drawing and world transforms, and we're using an identity transform, text output remains the same. This precedent already exists in the codebase where win_text's transform paths also set GM_ADVANCED without restoring the mode.

For non-GDI+ builds, win_emoji_show is just a stub, so no concerns there. The winimgs_paint function stays direct-to-window since we bypass buffering whenever term.imgs.first is non-null, and sixel images only exist through that list.

Now I'm setting up patch 6 with the configuration infrastructure, adding a display_buffering boolean to the config struct with a default of true, creating the option table entry, and updating the documentation. For the implementation in wintext.c, I'm declaring the static variables for managing the paint buffer—the memory DC, backing bitmap, dimensions, and state flags—along with helper functions to determine whether buffering should be active.

Writing buffer management code... Writing buffer management code...

Now I need to verify that assert.h is available through the standard includes, and check how the search bar exclusion works with the buffered painting approach — the clip region set on the window DC before the buffer begins should persist through the BitBlt operation, so the search bar area should be handled consistently with the current behavior. I'm also defining an accessor function that returns the appropriate device context for painting terminal graphics like emojis, choosing between the back buffer during a buffered update or a fresh window DC otherwise.

For the release function, I need to handle the paired cleanup — when buffered, it's a no-op since we're using the shared back buffer; otherwise, release the temporary DC. The assertion checking that the passed DC matches the back buffer during buffered mode is there for sanity, though I should drop the unused parameter suppression since the parameter is actually used in the non-buffered branch.

The winimg.c integration is straightforward: replace the direct GetDC/ReleaseDC calls with the new accessor functions, and make sure the declarations are visible by checking the include chain.

For do_update, I'm wrapping term_paint with the buffer begin/end calls, and winimgs_paint runs after to handle any image rendering or cleanup. The key thing is verifying the sync hazards: the horclip transform behavior is consistent between buffered and unbuffered paths, the UPDATE_PENDING check still prevents stale painting, term_invalidate gets called with the right bounds, and winimgs_paint's image list cleanup still executes even when the buffer is active.

Now I'm checking edge cases with overlays and glyphs that extend beyond the blit rectangle—italic characters might lose a pixel or two at the left edge where they overhang into the padding, but that's visually consistent since the padding-clearing calls become no-ops anyway. The cursor, selection highlight, and blinking all flow through term_paint into the buffer correctly, so there's no flicker. Window transparency via SetLayeredWindowAttributes is unaffected by the buffering since it's post-composition.

For BitBlt with 32-bit pixels, the alpha channel gets copied as-is (garbage or zero), which is neutral—same as direct GDI writes. Given that staleness tracking handles mode transitions, emoji routing works, sixel/tek/horclip are bypassed, and WM_PAINT is covered, I'm going with the feature on by default with an opt-out, documenting the residual overhang bleed suppression. Resizing while painting is safe since it's single-threaded with no reentrancy, and minimized windows skip painting via the existing iconic check. The buffer stays allocated until a size change—33MB at 4K is acceptable. Now moving to patch 7 for run merging in the term.c third loop, where I need to track an unshaped_ascii variable computed once per term_paint.

Modifying the bidi-class section... I need to declare prev_ascii alongside bc in the per-line variable initialization block that comes after the overlay: label, since both get re-initialized on re-entry. The comcom interaction that cancels breaks happens after the bidi-class logic, and my forced ASCII break getting cancelled by comcom characters is actually the existing intended behavior—composed combining characters merge with whatever precedes them, so this maintains the status quo.

For the commit message, I'm establishing that with unshaped_ascii, every chunk reaching win_text is either pure ASCII (rendered pixel-identically by ExtTextOutW regardless of boundaries) or contains non-ASCII with splits that differ only by the new ASCII/non-ASCII boundaries and comcom-cancelled cases. Under FR_TEXTOUT there's no shaping anywhere so splits are pixel-neutral; under Ligatures=0 with Uniscribe, non-ASCII chunks lose adjacent-ASCII shaping context which could affect glyph selection for context-sensitive fonts—this is consistent with the option's semantics and should be documented. I need to extend the Ligatures=0 paragraph in the manual to note that ASCII characters are now excluded from the shaping context of adjacent non-ASCII characters, and mention how chunk merging affects display speed. I'm also adding a new manual section describing buffered display updates near DisplaySpeedup.

For the config changes, I'll add a display_buffering bool field next to display_speedup in the config struct—offcfg uses offsetof so placement is flexible, and the designated initializers in default_cfg mean I can put it anywhere. I need to verify that term_allrows is accessible in wintext.c (it's already used in do_update for cell_height * term_allrows), check that assert is available (likely through std.h), and confirm the declaration pattern for win_get_paint_dc in winpriv.h. Then I'll prepare commits 6 and 7, validate they apply cleanly, and check if the wcw unit test needs updates.

With DisplaySpeedup=0 and buffering enabled, find ~/ should hit around 25-45fps with no tearing, though the total runtime increases since painting more frames costs CPU—DisplaySpeedup remains the user's control for throughput and smoothness, and FontSmoothing can serve as another lever for raster costs.

I've confirmed win_emoji_show already handles transform restoration and uses a single GetDC/ReleaseDC pair, so routing through a shared paint DC should work cleanly. Now I'll check the remaining integration points.

I'm checking what's available in the codebase — the standard assertions, the includes in winimg.c, the horclip function in win.h, and confirming that term.imgs.first exists and is used in winimgs_paint. I also found cfg.display_speedup at config.h:217. Now I need to write patch 6 across several files: config.h, config.c, docs/mintty.1, wintext.c, winimg.c, and winpriv.h where I'll declare the accessors. Let me check winpriv.h for the right spot to add the declarations since it already has extern declarations for wintext functions.

I'm examining the buffer state in wintext.c near the global dc and the begin/end/accessor functions above do_update.

Looking at the assert behavior with NDEBUG builds — the pdc variable gets used in the if branch for ReleaseDC, so there's no unused parameter warning even though it would be unused in the else branch when the assert expands to nothing. Mintty doesn't define NDEBUG anyway, so this isn't a practical concern. I'm also checking whether tek_mode is accessible in wintext.c, and since do_update already references it and tek.h is included, it should be available.

Now I need to verify the field names for the image structures — checking that term.imgs.first matches the actual struct definition in term.h, and I can see from the grep results that winimgs_paint already uses this field successfully. With those pieces confirmed, I'm ready to hook do_update and win_paint together.

Now I'm working on patch 7 to handle merging for unshaped ASCII text. I need to locate the bidi-class break block in term.c and find where bc is declared, then add unshaped_ascii at the top of term_paint and place prev_ascii alongside bc. I should also expand the Ligatures=0 manual section.

I need to correct my understanding of the code flow—the combined character cancellation check actually runs before the bidi-class evaluation, not after. This means the "no-break-run" condition is evaluated first, and only then does the code check whether the bidi class has changed.

Now I'm thinking through where to place my forced ASCII/non-ASCII break: if I put it inside the class-change block after the comcom cancellation, it won't interact with the cancellation logic itself. But this creates a problem—if a non-ASCII combined character follows an ASCII character, my forced break would fire and stay active (since it's not subject to comcom cancellation), which would separate the combined character from its base, defeating the intended grouping when the base is ASCII. The has_sea |= 2 flag only gets set when the cancellation path actually runs, so in a scenario with ASCII followed by a Thai combining mark, the flag wouldn't be set in the first place.

To handle this safely, I'll add a guard condition: when checking tascii != prev_ascii, I'll also exclude combined characters with && !is_comcom(tchar). This is a minimal, surgical fix that prevents the forced break from firing on combined characters while still allowing the break to work for other non-ASCII cases. The case where a combined character precedes ASCII is harmless since the combined character will have already joined its predecessor chunk.

I've identified that comcom cancellation needs to sit above the class-break block, which means I'll need to exempt comcom characters from forced ASCII↔non-ASCII breaks to preserve the composed combining character output behavior.

I'm verifying that the config header properly exposes the font rendering enum constant, so the comparison works correctly. Now I need to double-check the overlay loop logic in patch 7—specifically whether the variables declared after the overlay: label are accessible when the goto jumps back to that point.

Looking at the variable declarations, they're all re-initialized on each pass through the overlay loop, which is correct. I'm also confirming that is_comcom is properly declared and visible in the same function scope where it's used.

Before committing patch 7, I'm doing a final sweep of patch 6's diff to catch any compile-time issues: verifying that paint_buffer_usable has access to tek_mode through the header chain, checking that horclip() is available via the included headers, confirming all the term structure members and macros are in scope, and making sure the new helper functions are defined before do_update uses them and that win_paint can access them later in the file.

Now I need to verify that winpriv.h has the necessary headers included to support the HDC type in the new extern declarations, since other files like winimg.c include winpriv.h and work with HDC.

Let me trace through the patch 6 diff one more time to verify the clip region handling — specifically checking whether win_paint_exclude_search applies to the window DC before begin() is called, and confirming that the exclusion persists through the blit operation since begin() only swaps the global DC variable, not the underlying DC state itself.

The flow checks out: win_paint_exclude_search(dc) clips the window DC first; begin() redirects painting to the buffer; term_paint draws unclipped into the buffer; end() restores the window DC (which still carries the exclusion clip since DC state persists until ReleaseDC); then BitBlt applies the clipped region as intended. The horclip transform follows the same pattern — applied to the window DC before begin(), and if horclip is nonzero, begin() bypasses and paints directly to the transformed window DC. For WM_PAINT, the term_invalidate call happens before the paint branch, and if buffered, begin() may also invalidate everything, but the union is fine — the blit clips to rcPaint, and any content outside that region remains valid from the previous paint. The caret and scrollbar code after the paint branch runs with the DC already restored by end(), and ReleaseDC(wnd, dc) at the end of do_update releases the correct window DC. In win_paint, EndPaint works with the restored DC, and the padding fill section afterward uses the window DC correctly.

A few edge cases: paint_buffered won't be left true if term_paint longjmps abnormally — no such flow exists. Fullscreen and OFFSET are handled consistently in the blit y-coordinate. If cfg.display_buffering is toggled off at runtime, paint_buffer_usable becomes false and stale is set each frame, but the buffer memory (33MB) isn't freed until a size change — minor issue, acceptable. The new code passes -Werror checks: paint_buf_w/h, buffered, tascii, and prev_ascii are all used; no shadowing. The tek_mode check in paint_buffer_usable is redundant but harmless. GetClientRect includes the OFFSET area and search bar, so the buffer is sized to the full client and the blit rect is a subset — all consistent.

Now for the summary: the two mechanisms are the exclusion clip (applied to window DC, persists through BitBlt) and the buffer redirect (begin/end swap the DC target). The config knobs are DisplaySpeedup (0 or ≥10 disable skipping; values 1–9 enable it) and display_buffering (enables/disables the buffer). The semantics of DisplaySpeedup: skipping requires update_skipped < cfg.display_speedup AND cfg.display_speedup < 10, so both 0 and values ≥10 prevent skipping.

Patches 6 and 7 add the buffer infrastructure and the exclusion clip respectively; the expected outcome is reduced flicker and smoother scrolling, especially with high-frequency updates. Sixel, tek mode, and horizontal scroll auto-bypass the buffer. The main caveat is that patch 6 is invasive; DisplayBuffering=no provides an escape hatch if issues arise. There's a 1px padding overhang. Throughput tradeoff: painting more frames slows find completion, so DisplaySpeedup remains the primary dial. Citations: #835 (throughput design), #836 (non-atomic updates), manual DisplaySpeedup docs.

I've identified two key issues: there's a real GDI resource leak where DeleteObject is being called on a bitmap that's still selected into a device context—I need to reverse the order and delete the context first. Also, mintty already has DEC 2026 support implemented in its termout code for controlling update suspension.

Now I need to examine the termimgs struct fields to understand the alt-screen behavior, review the GDI state management in win_text to evaluate whether the caching patch is viable, and then look into what ghostty is doing.

I've confirmed the delete-order bug causes a ~33MB GDI bitmap leak per resize, and found that mintty already supports synchronized updates. Now I'll examine the sixel list structure and GDI state-call density in win_text.

Looking at the SetTextColor and SelectObject calls scattered throughout the text drawing code, there's a lot of interleaving with conditional state restoration for things like rainbow mode and shadow effects. A cross-run color and font cache would require wrapping around fifteen different sites with careful restore-order logic, but the regression risk outweighs the modest performance gain of a millisecond or two, so I'm deciding to skip GDI state caching for now and just document it as a potential optimization.

Now I need to verify how termimgs handles the altfirst and altlast pointers — winimgs_paint iterates through term.imgs.first, so when the screen switches, I should check whether mintty swaps first and altfirst to confirm my bypass condition is checking exactly what would be drawn.

The screen swap logic in term.c confirms my bypass condition is sound—the image list gets swapped between primary and alt, so only visible images are buffered. Now I'm looking into ghostty's performance techniques and development notes to verify and cite their renderer optimization approach.

I've confirmed the bypass condition tracks what winimgs_paint draws, but the color/font state-caching optimization would require proving restore discipline across ~15 interleaved sites with too much regression risk for minimal gain. Now I'll investigate ghostty.

The search results validate ghostty's architecture—the renderer thread stays decoupled from IO with minimal lock contention (20–40µs per frame), and the GPU re-renders the entire screen each frame rather than using damage regions like mintty does. This GPU decoupling is what keeps the framerate stable at 60fps even during heavy output like cat. I'm identifying which of these patterns could transfer to mintty's GDI approach, starting with decoupling frame pacing from the actual output stream.

The key insight is that ghostty's renderer samples terminal state at its own cadence (120Hz frames with a tiny lock) while IO runs independently at full speed—mintty's single-threaded equivalent would be tuning DisplaySpeedup to skip frames intelligently. Synchronized output is already in mintty's codebase, and I've got the dirty-span blit patch for damage-limited rendering. I have enough citations from the X post and the jpk review to support these points without fetching more.

Now I'm writing the first patch to fix the bitmap leak by properly deleting the device context before recreating the buffer.

Writing cleanup helper... Setting up the blit region with padding to account for double-height glyph spillover and pixel overhang, then handling the edge case where emoji might be drawn without a corresponding win_text call by recording the span in win_get_pa as a safety measure.

For the optimization experiment, I could enable -O2 compilation for wintext.c by editing the Makefile to replace the -O0 flag with -O2, though this is optional and marginal compared to the core fixes.

I should also verify that the emoji rendering path properly calls win_text for background handling, then finalize patches 8 and 9. The DEC 2026 sequence support with its 150ms cap already gives modern TUIs like recent neovim atomic frames when combined with DisplayBuffering. I've confirmed the dirty span logic handles the case where term_paint decides to paint nothing but the caller still blits, and I'm staying disciplined about not over-optimizing SetScrollInfo caching.

Ghostty's performance comes from architectural choices—decoupled rendering and GPU pipelines—that don't apply to mintty, but damage-limited blitting and synchronized output are worth adopting. I'll verify the emoji rendering path, then implement dirty-span blitting in patch 9 after fixing a leak in patch 8.