2

I have used OpenGL pretty exclusively for all my rendering, to the point that I'm unaware of any other way to write pixels to a window unfortunately.

This is a problem because my current project is a work tool that emulates an LCD display (pixel perfect, 2D, very few pixels are touched each frame, all 'drawing' can be done with memcpy() to a pixel buffer) and I feel that OpenGL might be too heavy for this, but I could absolutely be wrong in that assumption.

My goal is to borrow as little CPU time as possible. What's the best way to draw pixels to a window, in this limited way, on a modern typical machine running windows 10 circa 2019? Is OpenGL suited for this type of rendering, or should I adopt another rendering method in this case? And if so, what would that method be?

edit:

I should also mention, OpenGL can be used right away for me. If rendering textured triangles with an optimal setup is the fastest method, then I can already do that. Anything that just acts as an API over OpenGL or DirectX will likely be worse in my case.

edit2:

After some research, and thanks to the comments, I think I may just use OpenGL with Pixel Buffer Objects to optimize pixel uploads and keep rendering inexpensive.

Anne Quinn
  • 12,609
  • 8
  • 54
  • 101
  • What's wrong with GDI etc? – user253751 Nov 28 '19 at 11:30
  • 1
    @user253751 - nothing at all! I've never heard of them is all, and was hoping someone could point me at one that matches my use-case – Anne Quinn Nov 28 '19 at 11:34
  • 1
    Concerning _API over OpenGL_, this is the trap I ran into with Qt - `QPainter`. I had to draw head-up display (small coordinate-systems to remark origins of 3d objects) which I did in `QPainter` (the least effort to implement). The beta-testers tried this with 1000s of objects and complained about performance. After I reimplemented this stuff in OpenGL (with some fiddling to mix screen relative sizing correct with 3d to 2d transformation), the performance problems went away. I was always under impression that non-OpenGL rendering should be sufficiently fast for 2d stuff but I was wrong. – Scheff's Cat Nov 28 '19 at 12:03
  • Btw. if I remember right Qt has some kind of engine "under the hood" of `QPainter`. So, my 2d paintings might have been translated into inefficient OpenGL calls finally. On MS Windows with reasonable H/W, the rendering was stalled for seconds until the OS kicked in and recommend to exit the application due to possible driver issues. This happened for a total amount of maybe 30000 colored lines - not an issue at all if done properly in OpenGL directly. – Scheff's Cat Nov 28 '19 at 12:10
  • 1
    I would go with the texture approach. E.g. Qt's `QPainter` can paint off-screen i.e. into a `QPixmap` which then can be loaded as texture. I would wonder if other 2d APIs (like e.g. GDI) doesn't provide the same option. If it's actually about setting some individual pixels, strictly speaking, no 2d API is necessary. It could be reduced to simple array modification (and again texture upload). I wouldn't recommend this but to hammer your own 2d API for plain arrays can be fun as well: [SO: Midpoint thick ellipse drawing algorithm](https://stackoverflow.com/a/55983075/7478597). ;-) – Scheff's Cat Nov 28 '19 at 12:21
  • How do you create the window? And by the way OpenGL is certainly *an* option, but it might be unnecessarily complicated. On modern hardware it won't be slow. (On old hardware, it could've been. Nowadays, all the different drawing APIs all use the graphics card the same way. Windows uses DirectX to draw all the windows on the screen.) – user253751 Nov 28 '19 at 12:29

0 Answers0