[HN Gopher] LibNSFB - Framebuffer (bitmap on screen) abstraction...
___________________________________________________________________
LibNSFB - Framebuffer (bitmap on screen) abstraction library,
written in C
Author : peter_d_sherman
Score : 30 points
Date : 2024-10-25 18:15 UTC (4 hours ago)
(HTM) web link (www.netsurf-browser.org)
(TXT) w3m dump (www.netsurf-browser.org)
| peter_d_sherman wrote:
| >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 wrote:
| 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 wrote:
| 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.
| ChickeNES wrote:
| MiniFB is another option: https://github.com/emoon/minifb
| volemo wrote:
| I believe fenster [1] is an alternative.
|
| [1]: https://github.com/zserge/fenster
| kragen wrote:
| 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.
| Dwedit wrote:
| Dimensions, Pointer to Scanline 0, Stride, and Pixel Format. What
| else do you need before you start processing images?
___________________________________________________________________
(page generated 2024-10-25 23:00 UTC)