Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

FBG – Lightweight C Linux framebuffer graphics with parallelism

github.com

Post reply on HN
Print view View original

21–30 of 50 posts

Re: FBG – Lightweight C Linux framebuffer graphics with parallelism

#21

Post by vsampath »

userbinator wrote: post #15
codedokode wrote: post #8

It 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…

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? 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…

On a modern system (Windows 7+, Linux wth GRUB 2.0 bootloader) all of the drawing is done without the VBIOS; the VBIOS is just used to set up the mode.

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

Re: FBG – Lightweight C Linux framebuffer graphics with parallelism

#22

Post by 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.

Re: FBG – Lightweight C Linux framebuffer graphics with parallelism

#24

Post by raverbashing »

codedokode wrote: post #8

It 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…

> 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

No, it is as fast as it gets and it's the correct way of doing it (in fb at least).

Re: FBG – Lightweight C Linux framebuffer graphics with parallelism

#25

Post by 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.

Re: FBG – Lightweight C Linux framebuffer graphics with parallelism

#26

Post by saagarjha »

CharlesMerriam2 wrote: post #14

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.

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

Re: FBG – Lightweight C Linux framebuffer graphics with parallelism

#28

Post by dingdingdang »

biscuitNotchips wrote: post #25

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 t…

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.

Re: FBG – Lightweight C Linux framebuffer graphics with parallelism

#29

Post by stefan_ »

ChuckMcM wrote: post #22

"...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.

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.

Re: FBG – Lightweight C Linux framebuffer graphics with parallelism

#30

Post by pjmlp »

Vendan wrote: post #17
ajross wrote: post #9

Earlier quoted context omitted.

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.

Yeah, but linux framebuffer can do a very optimal swap... Just make the "virtual buffer" twice as tall, and then swap which "half" is "active" with a panDisplay IOCTL... That's why memcpy is such a bad idea, cause there is a very cheap method that can prevent tearing and such.

Ah memories of swapping card registers for double buffering on MS-DOS.

Here is a tutorial about it, that I just googled for.

http://www.brackeen.com/vga/unchain.html

Post reply on HN