FBGraphics was made to produce fullscreen pixels effects easily with non-accelerated framebuffer by leveraging multi-core processors, it is a bit like a software GPU (much less complex and featured!), the initial target platform is a Raspberry PI 3B and extend to the NanoPI (and many others embedded devices), the library should just work with many others devices with a Linux framebuffer altough there is at the moment some restrictions on the supported framebuffer format (24 bits).
FBGraphics is lightweight and does not intend to be a fully featured graphics library, it provide a limited set of graphics primitive and a small set of useful functions to start doing framebuffer graphics right away with or without multi-core support.
Neat project.
The initial commit on this project was *YESTERDAY* It’s had 13 commits in less than 24 hrs. Quite a few of those are to fix typos in the word ‘parallel’ and to fix file permissions. This thing is entirely unproven and the commit history reads like a comedy of errors. Why give this any press, at least at this stage?
Edited 2018-06-18 20:18 UTC
That’s what version control is for. Developers make errors, often stupid ones, regardless of how good they are normally. People spend too much effort trying to make their commit history looks nice when version control is there precisely so that you don’t have to worry about it.
Stranger than people who clean up commit history are people who judge projects based on commit history.
I can see this being very handy for cheap, low-power, four and eight core ARM systems that lack a GPU.
Not new.
In the early 00 years I used DirectFB on my laptop since X was painfully slow without proper hardware support…
directfb.net is dead.
directfb.org is now a strange blog about Linux and “How to prepare for the first sex?” – not joking!
Because that’s what us Linux users do, always preparing?
