There was a time when embedded system developers didn’t need to worry about graphics. When you have a PIC processor and two-line LCD, there isn’t much to learn. But if you are deploying Linux-based systems today, graphics are a real possibility. There are many options for doing Linux graphics including Wayland, X11, and frame buffers. Confused? This tutorial can help. The sections on Wayland and Mir are under construction, but that’s probably not what you are going to be using on a typical hacker project for the foreseeable future, anyway.
Of course, even inside those broad categories, you have multiple choices. If you are doing X11, for example, you can go low-level or pick any of a number of high-level libraries.
The tutorial assumes you understand C and basic Linux programming. It has two sections, really. One on how to plot points on the screen and another that covers basic graphics algorithms for drawing things like circles. We’d be interested in some benchmarks about the relative performance between the different raw drawing methods.
If you have a graphics-intensive application, the Raspberry PI 3 isn’t too bad. However, you can get dedicated hardware that will do better. You can even roll your own if you are so inclined.
And then there’s Ncurses for the “graphics” without graphics.
Curses is a bit rough to use, and it doesn’t work well with my serial terminal (tvipt).
That situation isn’t going to improve when someone uses actual graphics.
I started out with curses in a project (github.com/girst/minesviiper), only to then re-implement it with the few escape sequences I actually needed. ui-performance improved drastically. Curses is a nice prototyping tool, but unless you need all of its advanced features, you might be better off just doing it “by hand”. not too hard.
I use curses regularly in my UI development. Occasionally I use the curses library too… ;-)
Not that this isn’t useful, but sometimes I am reminded why I prefer bare-metal development.
The fact that it still says there’s going to be a section on Mir when Mir has been mostly dead since April gives me doubt that this tutorial is receiving much active development.
Linux framebuffer FTW! ;)
You always have CSS3 and HTML5 too ;) – https://www.youtube.com/watch?v=mPRXF4Npux8
…or just output your graphics in one of the NetPBM formats.
So simple, so useful!
Or, heck, PNG. It’s really not all that complicated. You’re right though, NetPBM is great if you need the simplest possible image format.
netpbm is neat. someone uses it for programming video effects here: http://nullprogram.com/blog/2017/07/02/
I made 4 videos on X11 graphics programming for anyone interested. Code on GitHub – https://www.youtube.com/playlist?list=PLGM1vdGv64r4HuZ8Rg0X6rNo3GjWsImQh
Graphics Tutorial without a single graphic !
How come so many embedded developers suck at UI’s?
UI is its own discipline. Someone good at embedded coding isn’t necessarily going to be good at UI. And vice versa.
Indeed. And a “nice” UI tends to eat up a lot of precious memory.
It’s not just embedded developers that suck at UI. There’s plenty of bad UIs across the spectrum.
I found the tutorial very informative and well written. Thanks!
The first example compiles and caused a seg fault when I ran it. Then I suspected that the fd0 device might need root permission so I ran it with sudo and now it turns my screen purple. It is not as the author wrote a fleeting effect so it is easy to note that the program worked.
The primitive shape code requires a function called draw() which is not defined anywhere.
Nice tutorial and collection of info. For embedded, this is really useful, even if you use only Debian with Python3 and PyQt5. Thanks.
Wow.
Really nice article keep the great work on.!
Rahul Gupta recently posted: python isdigit
Linux framebuffer FTW…………);
I would like to know apart from dumping to the /dev/fb0 which I got confused on /sys/class/graphics/fb0 vs fbcon… Which is the entire screen. It shows on the terminal console but not the screen.
Anyone help, graphical programming in Ubuntu fedora Linux at port layer or PCI card to CPU processing methods. FB graphic layer is direct to physical screen and to the daemon layer.