Question CS2 External — DiscordOverlay Performance & Frame Rendering Issues

[byte_corvus]

Anyone currently digging into the DiscordOverlay library for their CS2 external projects? I've been experimenting with hijacking Discord's overlay for rendering, but the performance overhead and stability are proving to be a massive pain in the ass.

The Goal
I'm attempting to render custom frames directly into Discord's overlay process to keep the external project's footprint low. The initial approach was simple—just a basic hook to send a frame.

namespace cs2_external.Discord
{
    public class Hook
    {
        public static void Start(Process process)
        {
            var frame = new Frame(1920, 1080);
            var processInfo = new GraphicsPipe.ConnectedProcessInfo { ProcessId = process.Id };
             if (!GraphicsPipe.ConnectToProcess(processInfo))
            {
                return;
            }
             Drawing.ClearCanvas(frame);
            Drawing.DrawString(frame, "Status: Active", 50, 50, SKColors.White, 13);
            GraphicsPipe.SendFrame(processInfo, frame.Width, frame.Height, frame.Buffer, frame.Size);
        }
    }
}

The Problem
This works for a static render, but the moment Discord does anything native—like receiving a call or opening a menu—the overlay breaks entirely. To combat this, I tried a continuous loop to force the frames, but it tanked the performance.

Spoiler: The While(True) Attempt

while (true)
{
    Drawing.ClearCanvas(frame);
    Drawing.DrawString(frame, "Rendering...", 50, 50, SKColors.White, 13);
    GraphicsPipe.SendFrame(processInfo, frame.Width, frame.Height, frame.Buffer, frame.Size);
}

Technical Roadblocks

1. The GraphicsPipe.SendFrame method is a massive bottleneck. Calling this every tick without any synchronization or frame-limiting logic is eating CPU cycles for breakfast.
2. Discord's own UI interaction seems to fight for the buffer. When the overlay state changes internally, my custom pipe gets pushed out or causes a flickering mess.
3. Memory management with SkiaSharp (SKColors) in a tight loop needs better handling to avoid leaks.

In my experience with these types of pipes, sending a full 1920x1080 buffer every single time is overkill. I'm looking for a way to optimize this—maybe delta updates or better threading logic.

Has anyone found a way to handle the conflict when Discord's native UI elements pop up during a call? I'm trying to keep this as clean as possible without going the full kernel-mode overlay route yet.

Anyone managed to get a stable 144Hz out of this pipe without the overlay shitting itself?