FBG – Lightweight C Linux framebuffer graphics with parallelism
1–10 of 50 posts
Re: FBG – Lightweight C Linux framebuffer graphics with parallelism
#2Is "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.
Re: FBG – Lightweight C Linux framebuffer graphics with parallelism
#3Raspberry Pi is a good example of where this would be quite useful (as per the readme). Nice work.
Re: FBG – Lightweight C Linux framebuffer graphics with parallelism
#4Is "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.
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
Re: FBG – Lightweight C Linux framebuffer graphics with parallelism
#5Is "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.
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.
Someone forgot to enable ML spell check for linter. With big data trained model, linter should be able to catch this.
Re: FBG – Lightweight C Linux framebuffer graphics with parallelism
#6Is "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.
A late night mistake that is mostly fixed. (and there are some other typo errors as well, will check it later on)
Thank you!
Re: FBG – Lightweight C Linux framebuffer graphics with parallelism
#7Is "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.
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.
Someone do a PR to him
Re: FBG – Lightweight C Linux framebuffer graphics with parallelism
#8It looks very ineffective. For example, in fbg_draw() they have this code:
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?
Re: FBG – Lightweight C Linux framebuffer graphics with parallelism
#9It looks very ineffective. For example, in fbg_draw() they have this code: 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 prot…
The memory mapped frame buffer is video memory, that's why you have to use a driver API to map it. Though obviously on many systems it ends up just being system dram with different caching settings anyway.
And this isn't something you'd code a game with, but you'd be surprised at how high modern memory bandwidth is.
Re: FBG – Lightweight C Linux framebuffer graphics with parallelism
#10Earlier quoted context omitted.
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.
Someone forgot to enable ML spell check for linter. With big data trained model, linter should be able to catch this.
A simple dictionary-based spell checker would be enough. Even vim ships with one of those.