https://github.com/grz0zrg/fbg/blob/master/src/fbgraphics.c#...
> 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?
And this isn't something you'd code a game with, but you'd be surprised at how high modern memory bandwidth is.
FB on modern computers work surprisingly well except for playing video or 3d graphics. Sometimes on BSD systems it is the only option.
I haven't looked into the details on Linux but on Windows the "default" VESA/VGA mode uses the VGA BIOS, whose code is run in 16-bit VM86 mode:
https://wiki.osdev.org/Virtual_8086_Mode#Usage
http://nuclear.mutantstargoat.com/articles/pcmetal/pcmetal04...
The 16-bit code is not optimised for speed (is your framebuffer more than 64K? It's probably doing bankswitching and only copying 64K at a time), and the video BIOS itself may reside behind a slow serial interface on the GPU[1] --- so executing from it is very slow.
[1] https://en.wikipedia.org/wiki/Serial_Peripheral_Interface_Bu...
The VBIOS is a 16-bit x86 application, but it does not run on these systems in vm86; reason being that mode is not supported in 64-bit long mode.
When the VBIOS does execute, it never does from Flash. SBIOS copies into system memory first.
Source: I’ve worked on VBIOS
No, it is as fast as it gets and it's the correct way of doing it (in fb at least).
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.
Thank you!
#define FBG_PARRALEL
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.
on the other hand, there are no nice animations, transitions and 3D effects like shadowing; just pixels on the screen; however everything updates instantly.
My only Linux system is a netbook with an AMD APU DX11 class, it used to work quite well, however after the AMD driver split performance was never as good and having back video hardware decoding required me to force enable it.
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.
However a single core memset (still RPI 3B) for this case is fast : 235 FPS
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.
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.
This is a single author's work to write a demonstration piece. Odd that is made the top five items on HackerNews.