anomalyco/opencode
1
0
Fork 0
mirror of https://github.com/anomalyco/opencode.git synced 2026-07-22 02:05:26 -04:00
Code Issues 5.9k Packages Projects Releases 19 Wiki Activity

[FEATURE]: Use GPU for Rendering the TUI (Better Performance + Smoothness) #2640

New Issue
Open
opened 2026-02-16 17:36:35 -05:00 by yindo · 2 comments
yindo commented 2026-02-16 17:36:35 -05:00
Owner
Copy Link
Copy Source

Originally created by @H0llyW00dzZ on GitHub (Nov 6, 2025).

Feature hasn't been suggested before.

  • I have verified this feature I'm about to request hasn't been suggested before.

Describe the enhancement you want to request

The current TUI implementation is already a significant improvement—it's responsive, handles complex layouts well, and provides a smooth user experience in most scenarios. However, for more demanding use cases (e.g., rendering large datasets, animations, or high-frequency updates in a terminal-like environment), CPU-bound rendering can introduce noticeable lag, especially on lower-end hardware or when scaling to larger displays.

Proposed Enhancement

I'd like to add optional GPU-accelerated rendering to the TUI backend. This could leverage libraries like:

  • Vulkan or OpenGL (via bindings like wgpu in Rust, or similar in other languages) for cross-platform GPU compute and rendering.
  • Ratatui (if this is a Rust-based TUI) or Textual (for Python) integrations with GPU offloading, or even WebGPU if the TUI has a web/hybrid component.
  • Fallback to CPU rendering for systems without GPU support, ensuring broad compatibility.

Key changes/additions:

  1. Rendering Pipeline: Offload text/layout computations and framebuffer updates to the GPU. For example, use shaders to handle glyph rendering, color gradients, and animations more efficiently.
  2. Configuration Option: Add a CLI flag or config setting (e.g., --gpu or tui.renderer = "gpu") to enable it, with auto-detection of compatible hardware (e.g., via winit or crossterm extensions).
  3. Performance Optimizations: Implement batched draws to minimize GPU calls, and use compute shaders for tasks like blurring or particle effects if the TUI supports them.
  4. Testing: Include benchmarks comparing CPU vs. GPU modes, targeting metrics like FPS during scrolls, redraws, and input handling.

Benefits

  • Improved Performance: GPU rendering could achieve 2-5x faster redraw rates for complex TUIs (e.g., dashboards with 1000+ elements), reducing latency from 50-100ms to under 10ms on modern GPUs.
  • Smoother Experience: Enables fluid animations, real-time updates (e.g., live charts or scrolling logs), and better handling of high-DPI displays without stuttering—ideal for interactive tools like file explorers, editors, or monitoring apps.
  • Scalability: Future-proofs the TUI for emerging hardware (e.g., integrated GPUs in laptops) and allows handling larger workloads without increasing CPU usage, which is great for battery life on portables.
  • User Impact: Developers and end-users on resource-constrained setups (e.g., remote SSH sessions or VMs) would notice snappier interactions, while power users with discrete GPUs get premium smoothness. It aligns with trends in terminal tech (e.g., GPU-accelerated terminals like Kitty or Alacritty).
Originally created by @H0llyW00dzZ on GitHub (Nov 6, 2025). ### Feature hasn't been suggested before. - [x] I have verified this feature I'm about to request hasn't been suggested before. ### Describe the enhancement you want to request The current TUI implementation is already a significant improvement—it's responsive, handles complex layouts well, and provides a smooth user experience in most scenarios. However, for more demanding use cases (e.g., rendering large datasets, animations, or high-frequency updates in a terminal-like environment), CPU-bound rendering can introduce noticeable lag, especially on lower-end hardware or when scaling to larger displays. ### Proposed Enhancement I'd like to add optional GPU-accelerated rendering to the TUI backend. This could leverage libraries like: - **Vulkan** or **OpenGL** (via bindings like `wgpu` in Rust, or similar in other languages) for cross-platform GPU compute and rendering. - **Ratatui** (if this is a Rust-based TUI) or **Textual** (for Python) integrations with GPU offloading, or even WebGPU if the TUI has a web/hybrid component. - Fallback to CPU rendering for systems without GPU support, ensuring broad compatibility. Key changes/additions: 1. **Rendering Pipeline**: Offload text/layout computations and framebuffer updates to the GPU. For example, use shaders to handle glyph rendering, color gradients, and animations more efficiently. 2. **Configuration Option**: Add a CLI flag or config setting (e.g., `--gpu` or `tui.renderer = "gpu"`) to enable it, with auto-detection of compatible hardware (e.g., via `winit` or `crossterm` extensions). 3. **Performance Optimizations**: Implement batched draws to minimize GPU calls, and use compute shaders for tasks like blurring or particle effects if the TUI supports them. 4. **Testing**: Include benchmarks comparing CPU vs. GPU modes, targeting metrics like FPS during scrolls, redraws, and input handling. ### Benefits - **Improved Performance**: GPU rendering could achieve 2-5x faster redraw rates for complex TUIs (e.g., dashboards with 1000+ elements), reducing latency from 50-100ms to under 10ms on modern GPUs. - **Smoother Experience**: Enables fluid animations, real-time updates (e.g., live charts or scrolling logs), and better handling of high-DPI displays without stuttering—ideal for interactive tools like file explorers, editors, or monitoring apps. - **Scalability**: Future-proofs the TUI for emerging hardware (e.g., integrated GPUs in laptops) and allows handling larger workloads without increasing CPU usage, which is great for battery life on portables. - **User Impact**: Developers and end-users on resource-constrained setups (e.g., remote SSH sessions or VMs) would notice snappier interactions, while power users with discrete GPUs get premium smoothness. It aligns with trends in terminal tech (e.g., GPU-accelerated terminals like Kitty or Alacritty).
yindo added the discussion label 2026-02-16 17:36:35 -05:00
yindo commented 2026-02-16 17:36:35 -05:00
Author
Owner
Copy Link
Copy Source

@github-actions[bot] commented on GitHub (Nov 6, 2025):

This issue might be a duplicate or related to existing performance issues. Please check:

  • #811: Text rendering is VERY slow (and CPU usage is really high even when idle) - addresses current TUI rendering performance problems
  • #2956: Evaluate migrating Go-based TUI to Ink (closed) - comprehensive TUI performance evaluation and migration discussion
  • #2083: significant performance regression with text animation - similar performance concerns with TUI rendering

While your request specifically focuses on GPU acceleration, these issues discuss the underlying TUI performance problems that your suggestion aims to solve. Feel free to ignore if none of these address your specific GPU acceleration proposal.

@github-actions[bot] commented on GitHub (Nov 6, 2025): This issue might be a duplicate or related to existing performance issues. Please check: - #811: Text rendering is VERY slow (and CPU usage is really high even when idle) - addresses current TUI rendering performance problems - #2956: Evaluate migrating Go-based TUI to Ink (closed) - comprehensive TUI performance evaluation and migration discussion - #2083: significant performance regression with text animation - similar performance concerns with TUI rendering While your request specifically focuses on GPU acceleration, these issues discuss the underlying TUI performance problems that your suggestion aims to solve. Feel free to ignore if none of these address your specific GPU acceleration proposal.
yindo commented 2026-02-16 17:36:35 -05:00
Author
Owner
Copy Link
Copy Source

@alkeryn commented on GitHub (Nov 7, 2025):

the rendering is your terminal emulator's job, not a tui program's.
use a gpu accelerated terminal emulator and your issue will be fixed.

@alkeryn commented on GitHub (Nov 7, 2025): the rendering is your terminal emulator's job, not a tui program's. use a gpu accelerated terminal emulator and your issue will be fixed.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
acp
bad
bug
discussion
docs
documentation
enhancement
extension
good first issue
growth
help-wanted
mcp
model-problem
needs:compliance
nix
opentui
perf
pull-request
Mirrored from GitHub Pull Request
 tui
web
windows
zen
No Label discussion
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
yindo
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: anomalyco/opencode#2640
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?