On 2020-04-24, Silvan Jegen <s.je...@gmail.com> wrote: > Yeah, that's where my missing understanding of graphics programming > becomes apparent. I assumed a font rendering library will just take a > pointer to some memory as an argument to its rendering function to which > it will then write the bitmapped glyph. Surely you will have to take the > different buffer formats into account there though so I am not sure how > that would work.
You would also have to consider how the glyph should be blended with the destination, whether you want to use mask image (for example to render in different colors or with transparency), and other details. Rendering the glyphs to separate images in a grayscale format gives the most flexibility. This also allows you to cache the glyphs so you don't have to re-render them all the time. > I'm also stomped by how the shared memory (like wl_shm) differs in Wayland > from a buffer you would get from EGL (like dmabuf-based wl_buffers) or > another graphics library. I thought I could just use pixman to render > into both but I don't think that's actually true... This example[0] > definitely looks relevant to this topic. The buffers you get from OpenGL/Vulkan are generally tiled in various vendor-specific (or even model-specific) formats, meaning they don't use a linear memory layout. If you were to render into it as if it were linear, you'd get jumbled output on the screen. The GPU memory is also not necessarily accessible by the CPU. There are ways to allocate an image in a linear layout backed by host-mappable memory, but that is likely to come with performance penalty (comparatively). Usually, you would only do this to upload textures to the GPU. Recently, most GPU vendors have agreed to settle on an opaque 64-bit "format modifier", which can be passed between APIs along with the DMA-BUF fd so they know how the image is laid out in memory. Previously, the image layout was either assumed, or passed along through some out-of-band channel (for example, AMD stores this information in a metadata structure associated with the buffer). I've been working off-and-on for a while on a library[0] to provide some sort of API to do simple 2D rendering and presentation operations that can be implemented with XRender, Vulkan, pixman, and also directly by submitting command buffers to the GPU. It's meant to be the successor to wld, but I still have a really long way to go, and have not begun to thing about how text rendering would work (but when I do, I'll definitely be looking at libschrift). [0] https://git.sr.ht/~mcf/libblit/