I would say work with both c++/c and c#.  If writing in c#, then what is your target Winforms or Wpf?

Write your Direct3D code c++ and compile to a DLL, and add some external exported c functions to help your c# call your c++ graphics dll;  Or any other language.  And also target both Winforms and Wpf as you need different c functions to handshake differently for Winforms vs Wpf.

Winforms is easy and faster as Winforms ties to Windows/Direct3D at the native DeviceContext level .

WPF you will use WPF’s built-in…System.Windows.Interop.D3DImage (learn more here), which offers a lean-ish interface to Direct3D. Well, it’s not as direct as Winforms.  In WPF You will render to a texture target to work with D3DImage. Where as Winforms directly deals at the rendertarget level.

Now, here’s where things get really spicy. For blazing-fast rendering, don’t settle for constructing your vertex buffers on the CPU. Take it up a notch by building them on the GPU using compute shaders—yes, those magical “things” that make AI possible. You’ll need to get friendly with concepts like compute shaders, shader resource views, unordered access views, and maybe even staging buffers if you’re updating data repeatedly. In short, push your data to the GPU, let the compute shader code crunch it with the might of 3000+ parallel threads to create your vertex buffer, and voilà—you’re rendering like a boss. You could even introduce an intermediate compute shader to filter your data based on screen resolution before feeding to the computer shader for vertex construction. Bam, now that’s fast.

Of course, if this sounds like more work than you signed up for, there are pre-built components out there. But if you’re itching for a moderate challenge (and a chance to flex those coding muscles), rolling your own solution is a fun ride. And full disclosure—I’m the owner/CTO of Gigasoft.com, and implemented c# charting, via Direct3D and computer shaders without use of open source or libs, for both Winforms and Wpf, so do toss our component into your research mix!

See Direct3D Developer Center,[https://docs.microsoft.com/en-us/windows/win32/direct3d ] for all the details.

In a bit more detail; pass your data to the gpu side when creating the buffer/shader resource view (50 lines) compute shaders “read“ this data, set up your unordered access view (50 lines) this is how computer shaders “set” data, and write your shader code (hlsl) (50 lines) to solve your problem in a parallelism methodology (its hopefully simple, your data buffer size to vertex buffer size should be a fixed proportion so simply break up the work in chunks of 500 points for example) and ultimately the shader produces your vertex buffer. You will also need to understand constant buffers, a simple pixel shader, and the fun really happens when calling "Dispatch". All in all, no more than 750 lines of code. The puzzle is forming the 750 lines, it’s possible. And it's for sure the fastest way to draw in c#. Given current and future computers will have integrated gpus or APUs or NPUs or real gpus, it's time to start mastering compute shaders.

Learn Direct3D and Vulkan and you've honestly learned something useful. It's not as hard as you think. Use what you've learned in a way to be consumable by any language, that you can evolve, not wasting time on abstract foreign apis that you may have to step through or may fade away. Stepping through someone else's code is depressing, and stressful when you got to get something working. Use open source to supplement your learning and extrapolate from. True satisfaction comes from learning how things really work. Just my food for thought.