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.
>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...
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
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.
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.
My own solution to this problem is 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.
Dimensions, Pointer to Scanline 0, Stride, and Pixel Format. What else do you need before you start processing images?
I believe fenster [1] is an alternative.
[1]: https://github.com/zserge/fenster
MiniFB is another option: https://github.com/emoon/minifb
>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!
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
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.
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.