Pixel snapping - #54728
Merged
Merged
Conversation
ConradIrwin
approved these changes
Apr 24, 2026
ConradIrwin
left a comment
Member
There was a problem hiding this comment.
Code changes make sense to me, and nothing is obviously broken (though I have only my macOS laptop's screen to test with)
Paulo-21
pushed a commit
to Paulo-21/zed-backup
that referenced
this pull request
Apr 24, 2026
Reverts parts of zed-industries#54728, which seems to have causes scrolling issues in the terminal Release Notes: - N/A
ebaah46
pushed a commit
to ebaah46/zed
that referenced
this pull request
May 6, 2026
Reverts parts of zed-industries#54728, which seems to have causes scrolling issues in the terminal Release Notes: - N/A
kathbigra
pushed a commit
to kathbigra/zed
that referenced
this pull request
May 10, 2026
Painting primitives at non-integer pixel coordinates produces blurry output. Pixel snapping converts layout coordinates into integer device-pixel coordinates so painted edges land exactly on physical pixel boundaries. Non-integer coordinates can arise for several reasons, including: - flex distribution, percentages, centering, and text measurement can produce fractional element sizes and positions; - at fractional scale factors (for example 125% or 150%), integer logical-pixel values can map to non-integer device-pixel values. We pixel-snap by rounding in device-pixel space, after multiplying by `scale_factor`, so that snapping targets physical pixels. Bounds are divided by `scale_factor` before being returned to GPUI. Midpoints are rounded toward zero. This is a stylistic choice: a 1-logical-pixel line at 150% scale should render as 1 dp rather than 2 dp. Pixel snapping is done in two phases: 1. Pre-layout metric snapping. Before Taffy computes layout, all authored absolute lengths are rounded in `to_taffy`. This includes borders, padding, gaps, and explicit sizes. Custom-measured leaf nodes have their measured sizes rounded up to integer device-pixel lengths. 2. Post-layout edge snapping. After Taffy resolves the tree, layout relationships such as flex shares, grid tracks, percentages, and centering can produce new fractional edge positions. Boxes now have edges in absolute coordinates, and snapping must decide where those edges land on the device-pixel grid. Ideally, post-layout snapping would satisfy: - Edge closure. Two raw layout edges at the same absolute position should snap to the same pixel column. - Translation stability. A component's internal geometry should not change when it moves to a new absolute position. These goals are in tension because rounding is not associative. The simple local schemes make different tradeoffs: - Absolute edge rounding gives each window coordinate one answer, so coincident edges always close globally. But a span's snapped length is `round(far) - round(near)`, which may change by 1 dp as its absolute origin moves. - Parent-relative edge rounding rounds each child inside its parent's coordinate space. This guarantees translation stability, but a shared edge reached through different parents can accumulate different rounding, causing non-closure between cousins. - Length rounding rounds each width, height, and thickness independently and then places boxes from those rounded lengths. Sizes stay stable under translation, but neighboring boxes derive their shared boundary from different sources, so closure is not guaranteed. We apply absolute edge rounding for each element's outer box in post-layout rounding to preserve closure. Border and padding widths are not touched by post-layout rounding; they keep their pre-layout rounded value so that they remain stable under translation. This gives both closure and translation stability in the case that all local metrics are integer device-pixel lengths. Pre-layout rounding covers that in most cases. The exception is metrics resolved by layout relationships, such as percentages. Outer box edges will still close globally, and painted border widths are still snapped independently, but the raw content-box origin can carry a 1 dp residual into descendants. --- Fixes zed-industries#46360 Fixes zed-industries#44528 Fixes zed-industries#40282 Fixes zed-industries#42257 --- Release Notes: - Fixed potentially blurry appearance of UI elements when using fractional display scaling.
kathbigra
pushed a commit
to kathbigra/zed
that referenced
this pull request
May 10, 2026
Reverts parts of zed-industries#54728, which seems to have causes scrolling issues in the terminal Release Notes: - N/A
jonx
pushed a commit
to jonx/zed-aros
that referenced
this pull request
Jul 17, 2026
Painting primitives at non-integer pixel coordinates produces blurry output. Pixel snapping converts layout coordinates into integer device-pixel coordinates so painted edges land exactly on physical pixel boundaries. Non-integer coordinates can arise for several reasons, including: - flex distribution, percentages, centering, and text measurement can produce fractional element sizes and positions; - at fractional scale factors (for example 125% or 150%), integer logical-pixel values can map to non-integer device-pixel values. We pixel-snap by rounding in device-pixel space, after multiplying by `scale_factor`, so that snapping targets physical pixels. Bounds are divided by `scale_factor` before being returned to GPUI. Midpoints are rounded toward zero. This is a stylistic choice: a 1-logical-pixel line at 150% scale should render as 1 dp rather than 2 dp. Pixel snapping is done in two phases: 1. Pre-layout metric snapping. Before Taffy computes layout, all authored absolute lengths are rounded in `to_taffy`. This includes borders, padding, gaps, and explicit sizes. Custom-measured leaf nodes have their measured sizes rounded up to integer device-pixel lengths. 2. Post-layout edge snapping. After Taffy resolves the tree, layout relationships such as flex shares, grid tracks, percentages, and centering can produce new fractional edge positions. Boxes now have edges in absolute coordinates, and snapping must decide where those edges land on the device-pixel grid. Ideally, post-layout snapping would satisfy: - Edge closure. Two raw layout edges at the same absolute position should snap to the same pixel column. - Translation stability. A component's internal geometry should not change when it moves to a new absolute position. These goals are in tension because rounding is not associative. The simple local schemes make different tradeoffs: - Absolute edge rounding gives each window coordinate one answer, so coincident edges always close globally. But a span's snapped length is `round(far) - round(near)`, which may change by 1 dp as its absolute origin moves. - Parent-relative edge rounding rounds each child inside its parent's coordinate space. This guarantees translation stability, but a shared edge reached through different parents can accumulate different rounding, causing non-closure between cousins. - Length rounding rounds each width, height, and thickness independently and then places boxes from those rounded lengths. Sizes stay stable under translation, but neighboring boxes derive their shared boundary from different sources, so closure is not guaranteed. We apply absolute edge rounding for each element's outer box in post-layout rounding to preserve closure. Border and padding widths are not touched by post-layout rounding; they keep their pre-layout rounded value so that they remain stable under translation. This gives both closure and translation stability in the case that all local metrics are integer device-pixel lengths. Pre-layout rounding covers that in most cases. The exception is metrics resolved by layout relationships, such as percentages. Outer box edges will still close globally, and painted border widths are still snapped independently, but the raw content-box origin can carry a 1 dp residual into descendants. --- Fixes zed-industries#46360 Fixes zed-industries#44528 Fixes zed-industries#40282 Fixes zed-industries#42257 --- Release Notes: - Fixed potentially blurry appearance of UI elements when using fractional display scaling.
jonx
pushed a commit
to jonx/zed-aros
that referenced
this pull request
Jul 17, 2026
Reverts parts of zed-industries#54728, which seems to have causes scrolling issues in the terminal Release Notes: - N/A
pull Bot
pushed a commit
to mr-narender/zed
that referenced
this pull request
Jul 19, 2026
Restore an optimization that I mistakenly removed in zed-industries#54728. Drawing a quad with a border but no fill color will run the quad fragment shader for every transparent interior pixel, which is especially costly when the quad is large. Instead, split these quads into four non-overlapping strips that cover the regions where borders are painted. The side strips own the straight left and right edges, while the top and bottom strips own the horizontal edges and the rounded corners. Previously, this optimization only applied to borders drawn by the Taffy layout. I've decided to reinstate the logic directly in `paint_quad` so that the optimization can be applied more generally... though if this feels like too much policy, we can move it back. This reduces the GPU time spent painting a representative Zed scene by about 20% or so. Release Notes: - N/A
Merged
5 tasks
pull Bot
pushed a commit
to Zezo-Ai/zezo-ai
that referenced
this pull request
Jul 22, 2026
…ped scroll positions (zed-industries#61348) # Objective Fixes zed-industries#56136. The issue was initially reported while an agent was generating code. Later reports reproduced it during manual editing and with AI disabled, ruling out the agent as the cause. At fractional display scales, the editor's right-click context menu could fail to appear at specific discrete scroll positions. Scrolling one line at a time could make the menu alternate between hidden and visible, even when its anchor remained within the viewport. ## Solution The editor-specific changes in zed-industries#54728 started pixel-snapping the vertical scroll position used by `EditorElement` to derive and render visible rows. However, `Editor::display_to_pixel_point` continued using the raw scroll position for its visibility check and vertical projection. When a downward pixel snap crossed an integer display-row boundary, `EditorElement` treated the preceding row as the visible range start. `display_to_pixel_point` then rejected that row as being above the raw viewport. Mouse context menu layout returned early before inspecting the actual clicked anchor, leaving the menu state present without rendering its element. This change applies the same line-height and display-scale pixel snapping in `display_to_pixel_point`. Its visibility check and coordinate projection now use the coordinate space actually rendered by the editor. A test-support-only scale-factor setter was also added so GPUI tests can exercise fractional display scaling without depending on the host display. ## Testing Added a GPUI regression test using 100 plain-text lines so the editor can scroll. The test uses a `1.25` scale factor and a `14px` font with `1.3` relative line height. The resulting `18.2px` line height is rounded to `18px`, producing exactly `22.5` device pixels per row. At a raw scroll position of one row, midpoint-toward-zero snapping maps `22.5` device pixels to `22`, or approximately `0.978` rows. This reproduces the old boundary mismatch where the snapped visible range starts at row zero while the raw visibility check starts at row one. The test pins these values with precondition assertions. Row five and an in-bounds click keep the actual source visible, while checking the rendered bounds of the `Copy` item ensures the test does not pass merely because menu state was created. Manually verified that scrolling from the start of a document no longer makes the context menu alternate between hidden and visible. ## Self-Review Checklist: - [x] I've reviewed my own diff for quality, security, and reliability - [x] Unsafe blocks (if any) have justifying comments - [x] The content adheres to Zed's UI standards ([UX/UI](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist) and [icon](https://github.com/zed-industries/zed/blob/main/crates/icons/README.md) guidelines) - [x] Tests cover the new/changed behavior - [x] Performance impact has been considered and is acceptable ## Showcase Before: https://github.com/user-attachments/assets/e14c030f-1587-4172-aed2-fecfbfcb65ed After: https://github.com/user-attachments/assets/3080db1e-46eb-4e20-a619-b1608f233668 --- Release Notes: - Fixed editor right-click context menus intermittently failing to appear at certain scroll positions.
jolutz
pushed a commit
to jolutz/zed
that referenced
this pull request
Aug 8, 2026
Painting primitives at non-integer pixel coordinates produces blurry output. Pixel snapping converts layout coordinates into integer device-pixel coordinates so painted edges land exactly on physical pixel boundaries. Non-integer coordinates can arise for several reasons, including: - flex distribution, percentages, centering, and text measurement can produce fractional element sizes and positions; - at fractional scale factors (for example 125% or 150%), integer logical-pixel values can map to non-integer device-pixel values. We pixel-snap by rounding in device-pixel space, after multiplying by `scale_factor`, so that snapping targets physical pixels. Bounds are divided by `scale_factor` before being returned to GPUI. Midpoints are rounded toward zero. This is a stylistic choice: a 1-logical-pixel line at 150% scale should render as 1 dp rather than 2 dp. Pixel snapping is done in two phases: 1. Pre-layout metric snapping. Before Taffy computes layout, all authored absolute lengths are rounded in `to_taffy`. This includes borders, padding, gaps, and explicit sizes. Custom-measured leaf nodes have their measured sizes rounded up to integer device-pixel lengths. 2. Post-layout edge snapping. After Taffy resolves the tree, layout relationships such as flex shares, grid tracks, percentages, and centering can produce new fractional edge positions. Boxes now have edges in absolute coordinates, and snapping must decide where those edges land on the device-pixel grid. Ideally, post-layout snapping would satisfy: - Edge closure. Two raw layout edges at the same absolute position should snap to the same pixel column. - Translation stability. A component's internal geometry should not change when it moves to a new absolute position. These goals are in tension because rounding is not associative. The simple local schemes make different tradeoffs: - Absolute edge rounding gives each window coordinate one answer, so coincident edges always close globally. But a span's snapped length is `round(far) - round(near)`, which may change by 1 dp as its absolute origin moves. - Parent-relative edge rounding rounds each child inside its parent's coordinate space. This guarantees translation stability, but a shared edge reached through different parents can accumulate different rounding, causing non-closure between cousins. - Length rounding rounds each width, height, and thickness independently and then places boxes from those rounded lengths. Sizes stay stable under translation, but neighboring boxes derive their shared boundary from different sources, so closure is not guaranteed. We apply absolute edge rounding for each element's outer box in post-layout rounding to preserve closure. Border and padding widths are not touched by post-layout rounding; they keep their pre-layout rounded value so that they remain stable under translation. This gives both closure and translation stability in the case that all local metrics are integer device-pixel lengths. Pre-layout rounding covers that in most cases. The exception is metrics resolved by layout relationships, such as percentages. Outer box edges will still close globally, and painted border widths are still snapped independently, but the raw content-box origin can carry a 1 dp residual into descendants. --- Fixes zed-industries#46360 Fixes zed-industries#44528 Fixes zed-industries#40282 Fixes zed-industries#42257 --- Release Notes: - Fixed potentially blurry appearance of UI elements when using fractional display scaling.
jolutz
pushed a commit
to jolutz/zed
that referenced
this pull request
Aug 8, 2026
Reverts parts of zed-industries#54728, which seems to have causes scrolling issues in the terminal Release Notes: - N/A
jolutz
pushed a commit
to jolutz/zed
that referenced
this pull request
Aug 8, 2026
Restore an optimization that I mistakenly removed in zed-industries#54728. Drawing a quad with a border but no fill color will run the quad fragment shader for every transparent interior pixel, which is especially costly when the quad is large. Instead, split these quads into four non-overlapping strips that cover the regions where borders are painted. The side strips own the straight left and right edges, while the top and bottom strips own the horizontal edges and the rounded corners. Previously, this optimization only applied to borders drawn by the Taffy layout. I've decided to reinstate the logic directly in `paint_quad` so that the optimization can be applied more generally... though if this feels like too much policy, we can move it back. This reduces the GPU time spent painting a representative Zed scene by about 20% or so. Release Notes: - N/A
jolutz
pushed a commit
to jolutz/zed
that referenced
this pull request
Aug 8, 2026
…ped scroll positions (zed-industries#61348) # Objective Fixes zed-industries#56136. The issue was initially reported while an agent was generating code. Later reports reproduced it during manual editing and with AI disabled, ruling out the agent as the cause. At fractional display scales, the editor's right-click context menu could fail to appear at specific discrete scroll positions. Scrolling one line at a time could make the menu alternate between hidden and visible, even when its anchor remained within the viewport. ## Solution The editor-specific changes in zed-industries#54728 started pixel-snapping the vertical scroll position used by `EditorElement` to derive and render visible rows. However, `Editor::display_to_pixel_point` continued using the raw scroll position for its visibility check and vertical projection. When a downward pixel snap crossed an integer display-row boundary, `EditorElement` treated the preceding row as the visible range start. `display_to_pixel_point` then rejected that row as being above the raw viewport. Mouse context menu layout returned early before inspecting the actual clicked anchor, leaving the menu state present without rendering its element. This change applies the same line-height and display-scale pixel snapping in `display_to_pixel_point`. Its visibility check and coordinate projection now use the coordinate space actually rendered by the editor. A test-support-only scale-factor setter was also added so GPUI tests can exercise fractional display scaling without depending on the host display. ## Testing Added a GPUI regression test using 100 plain-text lines so the editor can scroll. The test uses a `1.25` scale factor and a `14px` font with `1.3` relative line height. The resulting `18.2px` line height is rounded to `18px`, producing exactly `22.5` device pixels per row. At a raw scroll position of one row, midpoint-toward-zero snapping maps `22.5` device pixels to `22`, or approximately `0.978` rows. This reproduces the old boundary mismatch where the snapped visible range starts at row zero while the raw visibility check starts at row one. The test pins these values with precondition assertions. Row five and an in-bounds click keep the actual source visible, while checking the rendered bounds of the `Copy` item ensures the test does not pass merely because menu state was created. Manually verified that scrolling from the start of a document no longer makes the context menu alternate between hidden and visible. ## Self-Review Checklist: - [x] I've reviewed my own diff for quality, security, and reliability - [x] Unsafe blocks (if any) have justifying comments - [x] The content adheres to Zed's UI standards ([UX/UI](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist) and [icon](https://github.com/zed-industries/zed/blob/main/crates/icons/README.md) guidelines) - [x] Tests cover the new/changed behavior - [x] Performance impact has been considered and is acceptable ## Showcase Before: https://github.com/user-attachments/assets/e14c030f-1587-4172-aed2-fecfbfcb65ed After: https://github.com/user-attachments/assets/3080db1e-46eb-4e20-a619-b1608f233668 --- Release Notes: - Fixed editor right-click context menus intermittently failing to appear at certain scroll positions.
HyacinthHaru
pushed a commit
to HyacinthHaru/z3rm
that referenced
this pull request
Aug 16, 2026
Restore an optimization that I mistakenly removed in zed-industries#54728. Drawing a quad with a border but no fill color will run the quad fragment shader for every transparent interior pixel, which is especially costly when the quad is large. Instead, split these quads into four non-overlapping strips that cover the regions where borders are painted. The side strips own the straight left and right edges, while the top and bottom strips own the horizontal edges and the rounded corners. Previously, this optimization only applied to borders drawn by the Taffy layout. I've decided to reinstate the logic directly in `paint_quad` so that the optimization can be applied more generally... though if this feels like too much policy, we can move it back. This reduces the GPU time spent painting a representative Zed scene by about 20% or so. Release Notes: - N/A (cherry picked from commit 0c51c7f)
playdohface
pushed a commit
to playdohface/zed
that referenced
this pull request
Aug 29, 2026
Restore an optimization that I mistakenly removed in zed-industries#54728. Drawing a quad with a border but no fill color will run the quad fragment shader for every transparent interior pixel, which is especially costly when the quad is large. Instead, split these quads into four non-overlapping strips that cover the regions where borders are painted. The side strips own the straight left and right edges, while the top and bottom strips own the horizontal edges and the rounded corners. Previously, this optimization only applied to borders drawn by the Taffy layout. I've decided to reinstate the logic directly in `paint_quad` so that the optimization can be applied more generally... though if this feels like too much policy, we can move it back. This reduces the GPU time spent painting a representative Zed scene by about 20% or so. Release Notes: - N/A
playdohface
pushed a commit
to playdohface/zed
that referenced
this pull request
Aug 29, 2026
…ped scroll positions (zed-industries#61348) # Objective Fixes zed-industries#56136. The issue was initially reported while an agent was generating code. Later reports reproduced it during manual editing and with AI disabled, ruling out the agent as the cause. At fractional display scales, the editor's right-click context menu could fail to appear at specific discrete scroll positions. Scrolling one line at a time could make the menu alternate between hidden and visible, even when its anchor remained within the viewport. ## Solution The editor-specific changes in zed-industries#54728 started pixel-snapping the vertical scroll position used by `EditorElement` to derive and render visible rows. However, `Editor::display_to_pixel_point` continued using the raw scroll position for its visibility check and vertical projection. When a downward pixel snap crossed an integer display-row boundary, `EditorElement` treated the preceding row as the visible range start. `display_to_pixel_point` then rejected that row as being above the raw viewport. Mouse context menu layout returned early before inspecting the actual clicked anchor, leaving the menu state present without rendering its element. This change applies the same line-height and display-scale pixel snapping in `display_to_pixel_point`. Its visibility check and coordinate projection now use the coordinate space actually rendered by the editor. A test-support-only scale-factor setter was also added so GPUI tests can exercise fractional display scaling without depending on the host display. ## Testing Added a GPUI regression test using 100 plain-text lines so the editor can scroll. The test uses a `1.25` scale factor and a `14px` font with `1.3` relative line height. The resulting `18.2px` line height is rounded to `18px`, producing exactly `22.5` device pixels per row. At a raw scroll position of one row, midpoint-toward-zero snapping maps `22.5` device pixels to `22`, or approximately `0.978` rows. This reproduces the old boundary mismatch where the snapped visible range starts at row zero while the raw visibility check starts at row one. The test pins these values with precondition assertions. Row five and an in-bounds click keep the actual source visible, while checking the rendered bounds of the `Copy` item ensures the test does not pass merely because menu state was created. Manually verified that scrolling from the start of a document no longer makes the context menu alternate between hidden and visible. ## Self-Review Checklist: - [x] I've reviewed my own diff for quality, security, and reliability - [x] Unsafe blocks (if any) have justifying comments - [x] The content adheres to Zed's UI standards ([UX/UI](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist) and [icon](https://github.com/zed-industries/zed/blob/main/crates/icons/README.md) guidelines) - [x] Tests cover the new/changed behavior - [x] Performance impact has been considered and is acceptable ## Showcase Before: https://github.com/user-attachments/assets/e14c030f-1587-4172-aed2-fecfbfcb65ed After: https://github.com/user-attachments/assets/3080db1e-46eb-4e20-a619-b1608f233668 --- Release Notes: - Fixed editor right-click context menus intermittently failing to appear at certain scroll positions.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Painting primitives at non-integer pixel coordinates produces blurry output. Pixel snapping converts layout coordinates into integer device-pixel coordinates so painted edges land exactly on physical pixel boundaries.
Non-integer coordinates can arise for several reasons, including:
We pixel-snap by rounding in device-pixel space, after multiplying by
scale_factor, so that snapping targets physical pixels. Bounds are divided byscale_factorbefore being returned to GPUI.Midpoints are rounded toward zero. This is a stylistic choice: a 1-logical-pixel line at 150% scale should render as 1 dp rather than 2 dp.
Pixel snapping is done in two phases:
to_taffy. This includes borders, padding, gaps, and explicit sizes. Custom-measured leaf nodes have their measured sizes rounded up to integer device-pixel lengths.Ideally, post-layout snapping would satisfy:
These goals are in tension because rounding is not associative. The simple local schemes make different tradeoffs:
round(far) - round(near), which may change by 1 dp as its absolute origin moves.We apply absolute edge rounding for each element's outer box in post-layout rounding to preserve closure. Border and padding widths are not touched by post-layout rounding; they keep their pre-layout rounded value so that they remain stable under translation.
This gives both closure and translation stability in the case that all local metrics are integer device-pixel lengths. Pre-layout rounding covers that in most cases. The exception is metrics resolved by layout relationships, such as percentages. Outer box edges will still close globally, and painted border widths are still snapped independently, but the raw content-box origin can carry a 1 dp residual into descendants.
Fixes #46360
Fixes #44528
Fixes #40282
Fixes #42257
Release Notes: