
FBG – Lightweight C Linux framebuffer graphics with parallelism - onirom
https://github.com/grz0zrg/fbg
======
codedokode
It looks very ineffective. For example, in fbg_draw() they have this code:

[https://github.com/grz0zrg/fbg/blob/master/src/fbgraphics.c#...](https://github.com/grz0zrg/fbg/blob/master/src/fbgraphics.c#L605)

> memcpy(fbg->buffer, fbg->disp_buffer, fbg->size);

So they don't flip buffers, and don't even use video memory for them, they
just copy data from buffer in main memory into a memory-mapped framebuffer.
This must be slow. Also it doesn't check for vblank and therefore doesn't
protect from tearing, but the description says they have "double buffering".

As a side note, I remember that framebuffer was very slow on a computer I had.
Without proprietary video card driver both Windows and Linux had troubles even
scrolling a window, it was very laggy. Why was unaccelerated VGA (or VESA?)
mode so slow, I wonder?

~~~
smallstepforman
VESA is suprisingly good with Haiku. Since most GPU manufacturers have ignored
Haiku, the community has spent some time getting the VESA driver as good as it
can get, and it is very respectable. Most users will not be aware that they
are running VESA, since Haiku still less laggy than it's contemporaries.

~~~
zlynx
Haiku is also one of the best performers in a virtual Spice display. It feels
faster and more responsive than a virtualized Fedora or Ubuntu.

------
biscuitNotchips
Sadly linux framebuffer is still inferior in comparison to Windows framebuffer

I'm running Windows 7 with a 14 yo gfx card (ATI Radeon 9250 - DirectX 8.1)
along with Windows 2000 drivers in compatibility mode and if you exclude some
minor tearing everything else is perfect.

Same configuration but this time in linux, on various distros, from the
lightest to the heaviest and the results are the opposite. heavy screen
tearing and choppy scrolling everywhere, and the weird thing is that i see
more Graphic Features enabled in the chrome://gpu/ in linux than i see in
windows on this ancient card, yet the overall performance is inferior in
linux.

~~~
dingdingdang
My experience is the exact same, I so want to be able to have a snappy low
latency desktop experience in Linux and it is just not happening. Today I run
a "lightweight" Ubuntu Mate workstation with an i7 + dedicated GPU and it's
still worse latency wise than my Windows XP PC was more than 15 years ago. Not
good. Really not good.

~~~
ddalex
This is not the experience I'm getting. I'm running XUbuntu Bionic with i3,
and the experience is butter smooth; makes Windows feel laggy and MacOS slow
as molasses

on the other hand, there are no nice animations, transitions and 3D effects
like shadowing; just pixels on the screen; however everything updates
instantly.

------
ChuckMcM
_"...produce fullscreen pixels effects easily with non-accelerated framebuffer
... the initial target platform is a Raspberry PI 3B"_

Of course the Raspberry Pi 3 B actually has a GPU but it is so entangled with
crap that someone invests their time in building a sub-par visual experience.
That is so very sad.

The computer business sucks so much these days.

~~~
stefan_
The RPi GPU and display subsystem have fully open source drivers in Linux and
userland (Mesa). If you are using the old blobs it's out of ignorance.

------
m45t3r
Is "parralel" a real word in English? I think the author meant "parallel"?

I am asking this because everywhere in the README.md and even the source code
itself uses "parralel", so this typo seems to be proposital. The author is
either using a uncommon way to write the word parallel, is not a native
speaker or there is some other reason.

~~~
m45t3r
BTW, the project itself seems interesting. However it may be strange for
someone to use this library because you need, for example, to do a:

    
    
        #define FBG_PARRALEL
    

For it to work, and for some people this typo will be infuriating or
distracting. I recommend the author to fix this typo.

~~~
webscalist
Someone forgot to enable ML spell check for linter. With big data trained
model, linter should be able to catch this.

~~~
yorwba
A simple dictionary-based spell checker would be enough. Even vim ships with
one of those.

~~~
Immortalin
I think parent was being sarcastic

------
quadcore
A suggestion for the benchmarks: add one where the screen is filled with a
solid color. I was getting 175fps on 1280x768 with a 1.5Ghz AMD back in 2003.

~~~
yason
So, such a microbenchmark marks the baseline for how fast you could get via
framebuffer.

That's like 6 ms per frame. If you spend a bit less than two thirds of the
time in rendering you could still get 60 fps. But that's still just crazy
slow.

The 175 fps at that resolution comes down to about 20-60 MB/s depending on
display depth. Memory peak transfer rates were _worst like that_ during the
1990's, then several hundreds of MB/s for regular speeds in the 2000's and are
measured in GB/s these days.

As long as we can reduce framebuffer access to shared memory (to eliminate
legacy transfer methods of pixels, if any) there's no reason we couldn't do
significantly better. Basically the display controller is reading the memory
and the cpu is writing it so we must share some of the bandwidth but still the
speeds should be so high that there's absolutely no reason we should ever see
visual jerkiness on framebuffer graphics, due to hardware.

~~~
quadcore
I was intentionally keeping 'for y for x' loops.

------
canadaduane
Raspberry Pi is a good example of where this would be quite useful (as per the
readme). Nice work.

~~~
s_ngularity
The Raspberry Pi has a GPU. Why wouldn't you use accelerated graphics?

~~~
ponchotek
Because you need to use proprietary graphics drivers for acceleration. Another
reason could be that you want to write more portable code that can run in your
RPi during the early stages of development and on a board with no GPU later
on.

~~~
seba_dos1
Actually, you don't. Raspberry Pi is still a proprietary platform (you need a
closed firmware blob on your SD card for it to boot), but open GPU driver is
now in Mesa and in some cases works better than the old proprietary one.

------
jwilk
Wait, is 320×240 at 42 fps supposed to be impressive?

~~~
AHTERIX5000
Yeah that is actually extremely slow unless the time goes into calculating
buffer contents and in that case it isn't really a benchmark of an FB
implementation but something else.

~~~
onirom
The time goes into calculating a fullscreen pixels-based effect (so yeah;
buffer contents), the point of this library is not the FB implementation which
is a simple / bare-metal one.

The point is to render graphics content in a consistent way across multiple
CPU cores but still remain lightweight enough to be used with your own
implementation, this might change but that was the initial goal.

------
aparashk
I would have thought the vector capabilities of ARM and Intel architectures
would have been useful here, in addition to any multi-threadedness. They can
be used to add fast GPU like functions, e.g. alpha blending.

~~~
gameswithgo
handmade hero did a software renderer using SIMD instructions with very good
results:

[https://www.twitch.tv/videos/8349645](https://www.twitch.tv/videos/8349645)

------
MayeulC
How does it compare to llvmpipe, for instance? I expect llvmpipe to be able to
use neon (vector extension on ARM) instructions, as well as similar SIMD
mechanisms on other platforms.

------
chme
Interesting. But in a modern Linux graphics library I would expect the usage
of libdrm to paint instead of the /dev/fb interface.

------
CharlesMerriam2
Hmm.. 1. This is being announced on GitHub, a Microsoft entity; 2. there are
typos everywhere in the documentation; 3. the code is generally undocumented.

This is a single author's work to write a demonstration piece. Odd that is
made the top five items on HackerNews.

~~~
saagarjha
You mean, like essentially every other personal project that ends up on Hacker
News because it's cool?

