MEMLAYER(3)

πŸ“¦ version 0_git20260208, in alpine 3.24, arch rolling, nixos 26.05, nixpkgs unstable

πŸ’… MEMLAYER(3) β€” windows of memory-resident images πŸ’…

✨ NAME ✨

Bestie, this is the whole squad: memdraw, memlalloc, memldelete, memlexpose, memlfree, memlhide, memline, memlnorefresh, memload, memunload, memlorigin, memlsetrefresh, memltofront, memltofrontn, memltorear, memltorearn β€” all here for windows of memory-resident images. πŸͺŸπŸ’Ύ

πŸ’… SYNOPSIS πŸ’…

#include <u.h>
#include <libc.h>
#include <draw.h>
#include <memdraw.h>
#include <memlayer.h>

typedef struct Memscreen Memscreen;
typedef struct Memlayer Memlayer;
typedef void (*Refreshfn)(Memimage*, Rectangle, void*);

struct Memscreen
{
    Memimage  *frontmost; /* frontmost layer on screen */
    Memimage  *rearmost;  /* rearmost layer on screen */
    Memimage  *image;     /* upon which all layers are drawn */
    Memimage  *fill;      /* if non-zero, picture to use when repainting */
};

struct Memlayer
{
    Rectangle screenr;    /* true position of layer on screen */
    Point     delta;      /* add delta to go from image coords to screen */
    Memscreen *screen;    /* screen this layer belongs to */
    Memimage  *front;     /* window in front of this one */
    Memimage  *rear;      /* window behind this one*/
    int       clear;      /* layer is fully visible */
    Memimage  *save;      /* save area for obscured parts */
    Refreshfn refreshfn;  /* fn to refresh obscured parts if save==nil */
    void      *refreshptr;/* argument to refreshfn */
};

Memimage* memlalloc(Memscreen *s, Rectangle r, Refreshfn fn, void *arg, ulong col)

void      memlnorefresh(Memimage *i, Rectangle r, void *arg)

int       memlsetrefresh(Memimage *i, Refreshfn fn, void *arg)

int       memldelete(Memimage *i)

int       memlfree(Memimage *i)

int       memlexpose(Memimage *i, Rectangle r)

int       memlhide(Memimage *i, Rectangle r)

void      memltofront(Memimage *i)

void      memltofrontn(Memimage**ia, int n)

void      memltorear(Memimage *i)

void      memltorearn(Memimage **ia , int n)

int       memlorigin(Memimage *i, Point log, Point phys)

void      memdraw(Image *dst, Rectangle r,
             Image *src, Point sp, Image *mask, Point mp, Drawop op)
int       memload(Memimage *i, Rectangle r,
            uchar *buf, int n, int iscompressed)

int       memunload(Memimage *i, Rectangle r,
            uchar *buf, int n)

πŸ¦‹ DESCRIPTION πŸ¦‹

Okay so picture this, bestie: these functions build on the memdraw(3) interface to keep track of overlapping graphical windows on in-memory images. They’re the kernel’s little backstage crew for the windows interface that draw(3) and window(3) serve up, and the original page is fr fr honest: they probably have little use outside the kernel. πŸ’€

the core glow-up: Memimage β†’ Memlayer

The basic move is extending the definition of a Memimage (peep memdraw(3)) so it can include overlapping windows defined by the Memlayer type. The first fields of the Memlayer structure are identical to those in Memimage, which means a function that expects a Memimage can be passed a Memlayer, and vice versa. Both structures have a save field: it’s nil in a Memimage, and in a Memlayer it points to backing store. The layer routines accept Memimages or Memlayers; if the image is a Memimage, the underlying Memimage routine gets called; otherwise the layer routines recursively subdivide the geometry, shrinking the operation into a smaller component that ultimately can be performed on a Memimage β€” either the display on which the window appears, or the backing store. The way that recursion eats geometry is giving main character energy. ✨

Memscreen setup

Memlayers are associated with a Memscreen that holds the data structures to maintain the windows and connects them to the associated image. The fill color is used to paint the background when a window is deleted. There is no function to establish a Memscreen; to create one, you allocate the memory, zero frontmost and rearmost, set fill to a valid fill color or image, and set image to the Memimage (or Memlayer) on which the windows will be displayed. DIY screen construction, iykyk. πŸ› οΈ

allocating + refresh behavior

Memlalloc allocates a Memlayer of size r on Memscreen s. If col is not DNofill, the new window will be initialized by painting it that color. 🎨

The refresh function fn and associated argument arg will be called by routines in the library to restore portions of the window uncovered due to another window being deleted or this window being pulled to the front of the stack. When it’s called, the function receives a pointer to the image (window) being refreshed, the rectangle that has been uncovered, and the arg recorded when the window was created. A couple of predefined functions provide built-in management methods: memlnorefresh does no backup at all, useful for making efficient temporary windows; while a nil function specifies that the backing store (Memlayer.save) will be used to keep the obscured data. Other functions may be provided by the client. Memlsetrefresh allows one to change the function associated with the window. 🫢

delete / free / expose / hide

Memldelete deletes the window i, restoring the underlying display. Memlfree frees the data structures without unlinking the window from the associated Memscreen or doing any graphics. Lowkey different jobs, bestie. πŸ’…

Memlexpose restores rectangle r within the window, using the backing store or appropriate refresh method. Memlhide goes the other way, backing up r so that that portion of the screen may be modified without losing the data in this window. πŸͺŸ

stack ordering

Memltofront pulls i to the front of the stack of windows, making it fully visible. Memltofrontn pulls the n windows in the array ia to the front as a group, leaving their internal order unaffected. memltorear and memltorearn push the windows to the rear. Stack ’em, rearrange ’em, slay. πŸ‘‘

origin

Memlorigin changes the coordinate systems associated with the window i. The points log and phys represent the upper left corner (min) of the window’s internal coordinate system and its physical location on the screen. Changing log changes the interpretation of coordinates within the window; for example, setting it to (0, 0) makes the upper left corner of the window appear to be the origin of the coordinate system, regardless of its position on the screen. Changing phys changes the physical location of the window on the screen. When a window is created, its logical and physical coordinates are the same, so:

memlorigin(i, i->r.min, i->r.min)

would be a no-op. Cute, right? πŸŽ€

drawing + loading

memdraw and memline are implemented in the layer library but provide the main entry points for drawing on memory-resident windows. They have the signatures of memimagedraw and memimageline (see memdraw(3)) but accept Memlayer or Memimage arguments both. No cap. ✍️

memload and memunload are similarly layer-savvy versions of loadmemimage and unloadmemimage. The iscompressed flag to memload specifies whether the n bytes of data in buf are in compressed image format (see image(7)). πŸ—œοΈ

🌸 SOURCE 🌸

/src/libmemlayer

πŸŽ€ SEE ALSO πŸŽ€


kisses and sparkles πŸ’– β€” this has been the MEMLAYER(3) page from the Library Functions Manual, source/version vibes: Library Functions Manual / MEMLAYER(3), and the date? bestie, there’s literally no date line on this one, so consider it undated ✨. Periodt. 🫢