5 ms·

LibNSFB – Framebuffer (bitmap on screen) abstraction library, written in C

peter_d_sherman 2y ago
>LibNSFB: "The overall idea of the library is to provide a generic abstraction to a linear section of memory which corresponds to a visible array of pixel elements on a display [surface, context, software abstraction layer or] device Different colour depths are supported and the library provides routines for tasks such as drawing onto the framebuffer and rectangle copy operations. LibNSFB currently supports the following as framebuffer providers: Linux framebuffer X SDL VNC ABLE framebuffer" Absolutely beautiful -- and necessary! I was looking for a library like this that was not tightly coupled to other extraneous and unnecessary software (aka "bloatware") but could work across multiple graphics context providers, providing the same abstraction to each (i.e., software that is written for one software stack, i.e., X, automatically works for another software stack, i.e., SDL). Here we're not trying to be a game engine or a sound engine or anything else. We (by which I mean the developers!) are only trying to do one thing and do it right, and that's to abstract a graphical drawing surface, a bitmap, a "graphical viewport on the screen" across all of the above lower-level implementations. So, I was looking for something like this for some time... Well done!
- grisBeik 2y ago
  Sorry for being a party pooper, but it didn't take me 5 minutes to find an integer overflow in this code (which I've never seen before), as of commit 2443ff581ccd. The public function nsfb_set_geometry() takes "width" and "height" as "int" values. Assume those are positive. Then we pass them to nsfb->surface_rtns->geometry(). Assume our surface is implemented by "surface/ram.c"; thus the call is made to ram_set_geometry(). There we store the passed-in "int" params into fields of "nsfb" (also ints). Then we do /* reallocate surface memory if necessary */ endsize = (nsfb->width * nsfb->height * nsfb->bpp) / 8; Unchecked multiplication between signed integers (nsfb->width * nsfb->height); not only can it overflow and yield a bogus result, if that happens, it's even undefined behavior. It's naive code.
  - jcelerier 2y ago
    I mean the integer overflow is the least of your problems. If you try to create a 64000*64000 texture most drivers are going to bark at you anyways in the best case.
    - snvzz 2y ago
      >If you try to create a 64000*64000 texture Huge texture was a quite famous Linux NVIDIA driver vulnerability.
  - kragen 2y ago
    It sounds like your concern is that if the caller of the public function nsfb_set_geometry() passes in certain arguments, they can invoke undefined behavior, because the function doesn't correctly handle the case where the desired framebuffer is larger than 256 mebibytes (assuming 32-bit ints), and it may suffer an integer arithmetic overflow. That doesn't seem very surprising; nearly any function in C can be crashed by passing it invalid arguments. For example, printf((char)37), free((char)main), or memcpy(argv[0], argv[1], 10485760). Perhaps your concern is that the 256-mebibyte limitation isn't documented? libnsfb in general has very little documentation; this is the only documentation I see for nsfb_set_geometry(): /** Alter the geometry of a surface * * @param nsfb The context to alter. * @param width The new display width. * @param height The new display height. * @param format The desired surface format. */ int nsfb_set_geometry(nsfb_t *nsfb, int width, int height, enum nsfb_format_e format); The README says: API documentation ----------------- Currently, there is none. However, the code is well commented and the public API may be found in the "include" directory. The testcase sources may also be of use in working out how to use it. So I would say that, if you're concerned about documentation, there are much greater deficiencies in documentation than the documentation of this particular limitation. Perhaps your concern is that 256 mebibytes is actually a reasonable size for a framebuffer, not an invalid argument? With the 32-bit formats all modern displays seem to use, that would be 8192 × 8192. That seems like a colorable argument; I've worked with some images larger than that since last millennium. But it still seems serviceable for most purposes. With 16-bit ints, it could fail if the framebuffer was larger than 4096 bytes, which seems like a more serious problem, but I don't know if libnsfb can be built on 16-bit and 8-bit platforms.
ChickeNES 2y ago
MiniFB is another option: https://github.com/emoon/minifb https://github.com/emoon/minifb
volemo 2y ago
I believe fenster [1] is an alternative. [1]: https://github.com/zserge/fenster https://github.com/zserge/fenster
- snvzz 2y ago
  >keyboard, audio, mouse, timers Nah, this looks more like an alternative to SDL at that point.
kragen 2y ago
My own solution to this problem is Yeso: https://gitlab.com/kragen/bubbleos/-/tree/master/yeso https://gitlab.com/kragen/bubbleos/-/tree/master/yeso Under 20 kilobytes, 24-bit TrueColor only, with backends for X-Windows and the Linux framebuffer, and frontends for C, Python, and LuaJIT, and also providing keyboard and mouse events and loading of PNG and JPEG files (via libpng and libjpeg) and some half-baked text rendering stuff. Fenster looks great too. I hadn't seen LibNSFB or miniFB before.
Dwedit 2y ago
Dimensions, Pointer to Scanline 0, Stride, and Pixel Format. What else do you need before you start processing images?
- pavlov 2y ago
  If they are video frames, you also need to know the chroma subsampling ratio and separate stride values for luma and chroma. (Some systems also allow for separate base offsets for the chroma planes, but that’s not useful in practice. It’s simpler if you can assume that the chroma planes tightly follow the luma. Stride is enough for alignment.)
snvzz 2y ago
Also quite interesting, this is part of an original web browser project[0]. 0. https://www.netsurf-browser.org/ https://www.netsurf-browser.org/

>LibNSFB: "The overall idea of the library is to provide a generic abstraction to a linear section of memory which corresponds to a visible array of pixel elements on a display [surface, context, software abstraction layer or] device Different colour depths are supported and the library provides routines for tasks such as drawing onto the framebuffer and rectangle copy operations. LibNSFB currently supports the following as framebuffer providers: Linux framebuffer X SDL VNC ABLE framebuffer" Absolutely beautiful -- and necessary! I was looking for a library like this that was not tightly coupled to other extraneous and unnecessary software (aka "bloatware") but could work across multiple graphics context providers, providing the same abstraction to each (i.e., software that is written for one software stack, i.e., X, automatically works for another software stack, i.e., SDL). Here we're not trying to be a game engine or a sound engine or anything else. We (by which I mean the developers!) are only trying to do one thing and do it right, and that's to abstract a graphical drawing surface, a bitmap, a "graphical viewport on the screen" across all of the above lower-level implementations. So, I was looking for something like this for some time... Well done!

grisBeik 2y ago
Sorry for being a party pooper, but it didn't take me 5 minutes to find an integer overflow in this code (which I've never seen before), as of commit 2443ff581ccd. The public function nsfb_set_geometry() takes "width" and "height" as "int" values. Assume those are positive. Then we pass them to nsfb->surface_rtns->geometry(). Assume our surface is implemented by "surface/ram.c"; thus the call is made to ram_set_geometry(). There we store the passed-in "int" params into fields of "nsfb" (also ints). Then we do /* reallocate surface memory if necessary */ endsize = (nsfb->width * nsfb->height * nsfb->bpp) / 8; Unchecked multiplication between signed integers (nsfb->width * nsfb->height); not only can it overflow and yield a bogus result, if that happens, it's even undefined behavior. It's naive code.
- jcelerier 2y ago
  I mean the integer overflow is the least of your problems. If you try to create a 64000*64000 texture most drivers are going to bark at you anyways in the best case.
  - snvzz 2y ago
    >If you try to create a 64000*64000 texture Huge texture was a quite famous Linux NVIDIA driver vulnerability.
- kragen 2y ago
  It sounds like your concern is that if the caller of the public function nsfb_set_geometry() passes in certain arguments, they can invoke undefined behavior, because the function doesn't correctly handle the case where the desired framebuffer is larger than 256 mebibytes (assuming 32-bit ints), and it may suffer an integer arithmetic overflow. That doesn't seem very surprising; nearly any function in C can be crashed by passing it invalid arguments. For example, printf((char)37), free((char)main), or memcpy(argv[0], argv[1], 10485760). Perhaps your concern is that the 256-mebibyte limitation isn't documented? libnsfb in general has very little documentation; this is the only documentation I see for nsfb_set_geometry(): /** Alter the geometry of a surface * * @param nsfb The context to alter. * @param width The new display width. * @param height The new display height. * @param format The desired surface format. */ int nsfb_set_geometry(nsfb_t *nsfb, int width, int height, enum nsfb_format_e format); The README says: API documentation ----------------- Currently, there is none. However, the code is well commented and the public API may be found in the "include" directory. The testcase sources may also be of use in working out how to use it. So I would say that, if you're concerned about documentation, there are much greater deficiencies in documentation than the documentation of this particular limitation. Perhaps your concern is that 256 mebibytes is actually a reasonable size for a framebuffer, not an invalid argument? With the 32-bit formats all modern displays seem to use, that would be 8192 × 8192. That seems like a colorable argument; I've worked with some images larger than that since last millennium. But it still seems serviceable for most purposes. With 16-bit ints, it could fail if the framebuffer was larger than 4096 bytes, which seems like a more serious problem, but I don't know if libnsfb can be built on 16-bit and 8-bit platforms.

ChickeNES 2y ago

MiniFB is another option: https://github.com/emoon/minifb https://github.com/emoon/minifb

volemo 2y ago

I believe fenster [1] is an alternative. [1]: https://github.com/zserge/fenster https://github.com/zserge/fenster

snvzz 2y ago
>keyboard, audio, mouse, timers Nah, this looks more like an alternative to SDL at that point.

kragen 2y ago

My own solution to this problem is Yeso: https://gitlab.com/kragen/bubbleos/-/tree/master/yeso https://gitlab.com/kragen/bubbleos/-/tree/master/yeso Under 20 kilobytes, 24-bit TrueColor only, with backends for X-Windows and the Linux framebuffer, and frontends for C, Python, and LuaJIT, and also providing keyboard and mouse events and loading of PNG and JPEG files (via libpng and libjpeg) and some half-baked text rendering stuff. Fenster looks great too. I hadn't seen LibNSFB or miniFB before.

Dwedit 2y ago

Dimensions, Pointer to Scanline 0, Stride, and Pixel Format. What else do you need before you start processing images?

pavlov 2y ago
If they are video frames, you also need to know the chroma subsampling ratio and separate stride values for luma and chroma. (Some systems also allow for separate base offsets for the chroma planes, but that’s not useful in practice. It’s simpler if you can assume that the chroma planes tightly follow the luma. Stride is enough for alignment.)

snvzz 2y ago

Also quite interesting, this is part of an original web browser project[0]. 0. https://www.netsurf-browser.org/ https://www.netsurf-browser.org/