6 ms·

It looks very ineffective. For example, in fbg_draw() they have this code: https://github.com/grz0zrg/fbg/blob/master/src/fbgraphics.c#L605 https://github.com/

It looks very ineffective. For example, in fbg_draw() they have this code: https://github.com/grz0zrg/fbg/blob/master/src/fbgraphics.c#L605 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?

ajross 8y ago
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.
- Vendan 8y ago
  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.
  - pjmlp 8y ago
    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 http://www.brackeen.com/vga/unchain.html
  - onirom 8y ago
    I am aware of those, this might land in a future update. The library initial focus was just to get multiple cores to work for graphics task...
  - v_lisivka 8y ago
    With CRT monitors, it was possible to swap buffer in the middle of the frame, to display different buffers in different areas of the screen. It was used on 16bit systems for fast scrolling and to display status line.
userbinator 8y ago
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 https://wiki.osdev.org/Virtual_8086_Mode#Usage http://nuclear.mutantstargoat.com/articles/pcmetal/pcmetal04.html 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_Bus#Applications https://en.wikipedia.org/wiki/Serial_Peripheral_Interface_Bu...
- vsampath 8y ago
  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
smallstepforman 8y ago
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 8y ago
  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.
- waddlesplash 8y ago
  Honestly we haven't spent a massive amount of time on VESA, or really much optimization in general. It's not like there are a ton of magic tricks in there to make it fast or something. Somehow everyone else still manages to be slower than we are, though...
raverbashing 8y ago
> 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).
- Vendan 8y ago
  Linux frame buffer is perfectly capable of doing 2 pages and "flipping" without memcpy. Just have it initialize a double height virtual screen, and then use a panDisplay IOCTL to swap between them.
  - raverbashing 8y ago
    I see your point. You still need to copy the data to the buffer. But yeah, don't expect smooth animations without a dual buffer.
  - onirom 8y ago
    Tried to implement page flipping today and performances are terribly low on the Raspberry PI due to direct draw calls to the video mapped memory... so you need to do a single memcpy to avoid multiple write to the video mapped memory, this result in the initial behavior.
    - Vendan 8y ago
      Generate single frame, copy to "off page", flip. This prevents tearing.
      - onirom 8y ago
        Yes, this is actually how it work however page flipping mechanism require a memcpy, as such it is as effective as not using page flipping and just memcpy a front buffer to display and doing software flipping through pointers exchange, the only advantage of using page flipping is that it require much less operations and prevent tearing but performance wise, it is roughly the same.
pmarin 8y ago
>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? FB on modern computers work surprisingly well except for playing video or 3d graphics. Sometimes on BSD systems it is the only option.

ajross 8y ago

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.

Vendan 8y ago
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.
- pjmlp 8y ago
  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 http://www.brackeen.com/vga/unchain.html
- onirom 8y ago
  I am aware of those, this might land in a future update. The library initial focus was just to get multiple cores to work for graphics task...
- v_lisivka 8y ago
  With CRT monitors, it was possible to swap buffer in the middle of the frame, to display different buffers in different areas of the screen. It was used on 16bit systems for fast scrolling and to display status line.

userbinator 8y ago

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 https://wiki.osdev.org/Virtual_8086_Mode#Usage http://nuclear.mutantstargoat.com/articles/pcmetal/pcmetal04.html 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_Bus#Applications https://en.wikipedia.org/wiki/Serial_Peripheral_Interface_Bu...

vsampath 8y ago
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

smallstepforman 8y ago

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 8y ago
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.
waddlesplash 8y ago
Honestly we haven't spent a massive amount of time on VESA, or really much optimization in general. It's not like there are a ton of magic tricks in there to make it fast or something. Somehow everyone else still manages to be slower than we are, though...

raverbashing 8y ago

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

Vendan 8y ago
Linux frame buffer is perfectly capable of doing 2 pages and "flipping" without memcpy. Just have it initialize a double height virtual screen, and then use a panDisplay IOCTL to swap between them.
- raverbashing 8y ago
  I see your point. You still need to copy the data to the buffer. But yeah, don't expect smooth animations without a dual buffer.
- onirom 8y ago
  Tried to implement page flipping today and performances are terribly low on the Raspberry PI due to direct draw calls to the video mapped memory... so you need to do a single memcpy to avoid multiple write to the video mapped memory, this result in the initial behavior.
  - Vendan 8y ago
    Generate single frame, copy to "off page", flip. This prevents tearing.
    - onirom 8y ago
      Yes, this is actually how it work however page flipping mechanism require a memcpy, as such it is as effective as not using page flipping and just memcpy a front buffer to display and doing software flipping through pointers exchange, the only advantage of using page flipping is that it require much less operations and prevent tearing but performance wise, it is roughly the same.

pmarin 8y ago

>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? FB on modern computers work surprisingly well except for playing video or 3d graphics. Sometimes on BSD systems it is the only option.