---
title: "Rendering huge pull requests in the GitHub Copilot app"
description: "Rendering a pull request with over a million changed lines and hundreds of threaded comments requires a fundamentally different architecture than a code-only diff. The standard virtualized approach fails because comment heights depend on render-time factors like markdown wrapping, expandable sections, and reply composers. The team split the document’s height into two independent domains: deterministic code geometry and dynamic block geometry for comments. A single idle- and scroll-gated measurement pass, scoped to the viewport, corrects heights without causing reflows mid-scroll. The result is a pull request view where a million-line diff with hundreds of comments opens, scrolls, and behaves like a normally sized pull request."
---

# Rendering huge pull requests in the GitHub Copilot app

[Github](https://yomu.fyi/company/github) · Alberto Gimeno · Sep 23, 2026

**Type:** Problem & solution

## Summary

Rendering a pull request with over a million changed lines and hundreds of threaded comments requires a fundamentally different architecture than a code-only diff. The standard virtualized approach fails because comment heights depend on render-time factors like markdown wrapping, expandable sections, and reply composers. The team split the document’s height into two independent domains: deterministic code geometry and dynamic block geometry for comments. A single idle- and scroll-gated measurement pass, scoped to the viewport, corrects heights without causing reflows mid-scroll. The result is a pull request view where a million-line diff with hundreds of comments opens, scrolls, and behaves like a normally sized pull request.

## Context

The GitHub Copilot app needed to render extremely large pull requests (e.g., 2,200 files, over a million changed lines, 400+ inline comments) without jank or scroll jumps. Comments break the standard virtualized diff approach because their height depends on render-time factors like markdown wrapping, expandable sections, reply composers, and images. The team rebuilt the pull request view to handle this.

## Approach / What changed

Split the document’s height into two independent domains: deterministic code geometry (exact, known up front) and dynamic block geometry (estimated, then measured) for comments and other variable-height content. Use a single idle- and scroll-gated measurement pass scoped to the viewport, with permanent structured probes and an autonomous change-measure-improve loop to maintain performance.

## Takeaways

- Comment heights cannot be known before paint because they depend on markdown wrapping, expandable sections, reply composers, and async assets. This breaks the ‘all heights known before paint’ contract used for code-only diffs.
- Splitting the document into deterministic code geometry and dynamic block geometry prevents comment resizing from forcing a rebuild of the code offset table, keeping scroll jumps small and anchored to the viewport.
- A single idle- and scroll-gated measurement pass, scoped to the viewport and reading all mounted candidates in one batch, avoids the self-triggering feedback loop of per-block ResizeObservers.

## FAQ

### How does the app avoid scroll jumps from comment resizing?

The team split the document's height into two independent domains: deterministic code geometry (exact, known up front) and dynamic block geometry (estimated, then measured) for comments. A single idle- and scroll-gated measurement pass, scoped to the viewport, corrects heights without causing reflows mid-scroll.

### When does the app measure comment heights?

The measurement pass runs only when the visible range settles, never during a scroll frame. It reads every mounted candidate in one batch (a single reflow with no writes in between) and records the measured heights. Distant blocks keep riding their estimate and get corrected as they approach the viewport.

### How does the team verify performance invariants?

The surface carries permanent structured probes that answer questions on every render, such as how many rows and comment blocks are mounted, whether measurement coalesces to a single commit per frame, and whether any comment block was inserted after scrolling started. These are asserted as budgets in an end-to-end test against a synthetic fixture.

**Tags:** [GitHub Copilot](https://yomu.fyi/topic/github-copilot), [Performance](https://yomu.fyi/topic/performance), [Virtualization](https://yomu.fyi/topic/virtualization)

- Source: [Github](https://github.blog/engineering/user-experience/rendering-huge-pull-requests-in-the-github-copilot-app)
- Source URL: https://github.blog/engineering/user-experience/rendering-huge-pull-requests-in-the-github-copilot-app
- Ingested by Yomu: 2026-09-23T21:00:10.050Z

[Read original post](https://github.blog/engineering/user-experience/rendering-huge-pull-requests-in-the-github-copilot-app)