On 2020-04-24, Silvan Jegen <s.jegen_AT_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/
Received on Fri Apr 24 2020 - 21:17:17 CEST