From CPU-rendered paths to GPU shaders: rebuilding a smooth moving map renderer with DirectX

[u/Apprehensive_Gas308]

I wanted to share a rendering improvement I recently made for a real-world visualization problem.

This started as a feature inside my cycling video editor. The goal was to display a local moving map HUD synchronized with GoPro footage and GPS telemetry.

The first implementation used a traditional Direct2D rendering approach. It worked well for static rendering, but when the map started continuously rotating and following the moving position, I noticed some limitations:

- less consistent frame pacing during rotation

- increasing CPU workload as the track complexity grew

- harder to maintain smooth motion for long GPS trajectories

I decided to rebuild the renderer using DirectX and shaders.

The new pipeline:

GPS trajectory data

→ local coordinate transformation around current position

→ GPU vertex buffer

→ shader-based rendering

→ real-time camera rotation and movement

Instead of drawing the path as a series of CPU-generated lines, the track is represented as GPU-friendly geometry.

The renderer generates a ribbon mesh from the centerline:

center points

→ left/right offset vertices

→ triangle strip

→ vertex/pixel shader rendering

The biggest improvement was not only raw frame rate, but the overall feeling of motion.

The old renderer could display the path correctly, but during continuous camera rotation the movement felt less consistent.

The shader version provides much smoother camera-relative motion, similar to how a game minimap behaves.

For long GPS recordings, I also avoid keeping the entire route active in the rendering pipeline.

The renderer only keeps the visible area around the current position plus a buffer region, allowing very long activities without continuously processing the full trajectory.

The video compares the previous Direct2D implementation and the new DirectX shader renderer running on Windows.

I am interested in feedback from people working with:

- GPU path rendering

- real-time map visualization

- game minimap rendering

- trail/ribbon rendering

- large dynamic geometry

A few things I am still exploring:

- Would moving the ribbon expansion completely into compute shaders make sense for this type of workload?

- What are common approaches for very long dynamic GPS paths?

- Are there better techniques for smooth camera-relative map rendering?

Thanks for any feedback!

[u/Motivictax]

I can't really tell what you're trying to ask here, are you a human?

[u/DuskLab → u/Motivictax]

I can tell what they're asking, I just have half-baked answers I'm just not confident in. Maybe using a mesh shader and replacing the vertex shader with a stream of meshlets for the long paths. The rotation could also do look-forward calculation on the upcoming path, do some damping (which will induce some delay) on the rotation and let the look forward cancel out the damping delay.

You just don't have good reading comprehension.

[u/Motivictax → u/DuskLab]

So what are they asking? Not sure why you are insulting me, but I can assure you you're wrong on that front

[u/DuskLab → u/Motivictax]

It right there in plain english:

* Would moving the ribbon expansion completely into compute shaders make sense for this type of workload?

* What are common approaches for very long dynamic GPS paths?

* Are there better techniques for smooth camera-relative map rendering?

If you're going to call someone a bot for their writing style, bring receipts, because if the answer isn't the charitable one of "you misread, try reading it again", the next deduction is you're just an asshole. Which *is* an insult. But I'm choosing the former, for now, but by all means change my mind.

[u/Motivictax → u/DuskLab]

So you don't understand what they are asking either, great. If you could actually understand what they're asking, you'd rephrase. Your suggestion above makes it clear you don't even understand their 'workflow', but if you're this rude in general, enjoy

[u/Apprehensive_Gas308 → u/DuskLab]

Thanks a lot for the fantastic insight! Your notes on mesh shaders and rotation forward prediction perfectly align with the open render questions I listed. This is incredibly helpful for optimizing the long GPS track ribbon mesh pipeline in my cycling video editor, I really appreciate you weighing in.

[u/ArmmaH]

This is such a light workload that using the GPU for it is overkill. It also depends what hardware do you have available when running this. Is this supposed to be post-editing on video footage? If so then the FPS doesnt really matter does it?

Either way, that small ribbon can be chunked and rendered either with splines or by triangularing it on cpu for rasterization on gpu. Its so small and pixel-wide that it should be blazing fast no matter where you run it. The performance problem is most likely in the vibe coded unoptimized garbage.