Michael Forney <mforney_AT_mforney.org> wrote:
> 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.
Yes, that makes sense.
I have heard about the atlas approach that you have mentioned
before. There you render all the glyphs to some texture which you can then
blend with a texture that holds all the other stuff you want to render.
In the libSDL2 library, they even have a function to adjust color values
for textures so you can render the same glyph atlas in different colours
if you need colored text.
> > 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
Yeah, I figured something like this would end up happening in that case.
> 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 assume that means you would have to read these "format modifiers"
and then adjust the rendering in your library according to the format of
the two (or more) buffers that are involved. Since there will be quite
a few combinations this is a PITA, I would imagine.
> 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).
That sounds awesome and I will have a look for sure!
I have actually been looking at the wld source for a while since I have
an AMD Polaris card and thought it would be awesome to implement its
interface for the amdgpu driver. I didnt' get very far though since to
me it seems that the interface to what the AMD kernel driver exposes is
severely under-documented (at least for a novice like me). I couldn't
figure out where to get the memory from that wld can render into at all.
Cheers,
Silvan
>
> [0] https://git.sr.ht/~mcf/libblit/
Received on Sat Apr 25 2020 - 09:33:34 CEST