Re: [hackers] Announcing libschrift (a TrueType font rendering library)
Michael Forney wrote: > On 2020-04-24, Silvan Jegen 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/
Re: [hackers] Announcing libschrift (a TrueType font rendering library)
On 2020-04-24, Silvan Jegen 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/
Re: [hackers] Announcing libschrift (a TrueType font rendering library)
Hi Michael Thanks for your input! Michael Forney wrote: > On 2020-04-23, Silvan Jegen wrote: > > I had a quick look and currently it looks like it's mostly useful for > > rendering of fonts in X. I wonder how an interface would look like that > > could also be used for text rendering for a Wayland client. I assume the > > library would instead just render to some graphics memory to be rendered > > by the compositor, but I am not completely sure. > > I think the interface would look the same for Wayland, but the missing > piece is something to composite the glyphs into the application's > window buffer, which is handled by XRender in the demo. > > If you are rendering to shared memory, pixman (which is essentially > XRender in a library) can be used similarly. You can create a glyph > cache, load the glyph images produced by libschrift into it, and then > use pixman_composite_glyphs to render them onto your frame. > > For OpenGL/Vulkan, it's the same on X11 and Wayland, since the client > is doing direct rendering in both cases. I believe it's generally done > by creating an "atlas" texture containing a bunch of glyphs at > different positions, and then rendering subregions of it onto your > frame. Most code using freetype directly could probably be adapted to > libschrift fairly easily. 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. 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. These are the questions I will have to answer for myself before I will be able to contribute much there, I am afraid. Cheers, Silvan [0] https://github.com/wayland-project/weston/blob/master/clients/simple-dmabuf-egl.c
Re: [hackers] Announcing libschrift (a TrueType font rendering library)
On 2020-04-23, Silvan Jegen wrote: > I had a quick look and currently it looks like it's mostly useful for > rendering of fonts in X. I wonder how an interface would look like that > could also be used for text rendering for a Wayland client. I assume the > library would instead just render to some graphics memory to be rendered > by the compositor, but I am not completely sure. I think the interface would look the same for Wayland, but the missing piece is something to composite the glyphs into the application's window buffer, which is handled by XRender in the demo. If you are rendering to shared memory, pixman (which is essentially XRender in a library) can be used similarly. You can create a glyph cache, load the glyph images produced by libschrift into it, and then use pixman_composite_glyphs to render them onto your frame. For OpenGL/Vulkan, it's the same on X11 and Wayland, since the client is doing direct rendering in both cases. I believe it's generally done by creating an "atlas" texture containing a bunch of glyphs at different positions, and then rendering subregions of it onto your frame. Most code using freetype directly could probably be adapted to libschrift fairly easily.
Re: [hackers] Announcing libschrift (a TrueType font rendering library)
Hi Thomas Thomas Oltmann wrote: > Last year at slcon6, I demo'd a toy TrueType font renderer (*) to a > couple people. > Someone there suggested it'd be really useful to have this as a proper > library for suckless projects to use, > and so after a complete rework to make it actually usable, I'm finally > able to release it under the name libschrift! > You can find it here: https://www.github.com/tomolt/libschrift > > What you'll notice is that, similar to other font rendering libraries, > libschrifts API is very low-level; > In future, I'll probably write a wrapper library that abstracts away > most of this. > For right now, there's at least an example/demo application called sftdemo. > sftdemo shows how to use libschrift to render text to an X11 window > completely without Xft or FreeType2. > To do this, sftdemo uses the same underlying interface that Xft is > also built upon. > > Still, you shouldn't use libschrift for anything serious quite yet. > Most notably, compound glyph support is still missing, > so some characters like Umlauts or accents will likely not work yet. > > As a proof of concept, I might at some point write a patch for dmenu > (or something like it) > that replaces all of its Xft / FreeType2 usage with libschrift. > > I can keep you all posted if you're interested. That's a really cool project! I am interested in linguistics and, to a lesser degree, in 2D graphics. Lately I was thinking that I really should look into font rendering as that is where those two interests meet :P this library is a good starting point for me! I had a quick look and currently it looks like it's mostly useful for rendering of fonts in X. I wonder how an interface would look like that could also be used for text rendering for a Wayland client. I assume the library would instead just render to some graphics memory to be rendered by the compositor, but I am not completely sure. Cheers, Silvan
Re: [hackers] Announcing libschrift (a TrueType font rendering library)
Hi Hiltjo! > It looks interesting. I think it's useful if you're using the drw.c interfaces > (as a wrapper) for this. It can be found in the libsl repo: > > https://git.suckless.org/libsl/files.html Yeah that's probably the best course of action here. I'm just not quite sure how to do the matching of font names to concrete file paths; drw currently uses FontConfig for this, but I don't know if that thing can even work without FreeType2. > I've had a similar project based on a stripped-down/cleanup version of > stb_truetype: > https://github.com/nothings/stb/blob/master/stb_truetype.h Actually, stb_truetype has also been a bit of an inspiration for libschrift. Its author, Sean Barrett, has a great writeup of his rasterization algorithm, which was very helpful in getting me going. Since then though, I developed my own much simpler algorithm that relies on 2D raycasting instead of scanline rasterization (which is what stb_truetype does). Best regards, Thomas Oltmann
Re: [hackers] Announcing libschrift (a TrueType font rendering library)
On Sun, Apr 19, 2020 at 04:47:24PM +0200, Thomas Oltmann wrote: > Hello everybody. > > Last year at slcon6, I demo'd a toy TrueType font renderer (*) to a > couple people. > Someone there suggested it'd be really useful to have this as a proper > library for suckless projects to use, > and so after a complete rework to make it actually usable, I'm finally > able to release it under the name libschrift! > You can find it here: https://www.github.com/tomolt/libschrift > > What you'll notice is that, similar to other font rendering libraries, > libschrifts API is very low-level; > In future, I'll probably write a wrapper library that abstracts away > most of this. > For right now, there's at least an example/demo application called sftdemo. > sftdemo shows how to use libschrift to render text to an X11 window > completely without Xft or FreeType2. > To do this, sftdemo uses the same underlying interface that Xft is > also built upon. > > Still, you shouldn't use libschrift for anything serious quite yet. > Most notably, compound glyph support is still missing, > so some characters like Umlauts or accents will likely not work yet. > > As a proof of concept, I might at some point write a patch for dmenu > (or something like it) > that replaces all of its Xft / FreeType2 usage with libschrift. > > I can keep you all posted if you're interested. > > Cheers, > Thomas Oltmann > > > (*) For those wo don't know, a font renderer handles the low-level > parts of displaying text. > That entails parsing font files and using them to draw characters into > bitmaps at runtime, which can then be displayed on the screen. > Currently, all suckless applications (and in fact most applications in > general) use FreeType2 for this, mostly via a wrapper API called Xft. > Hi, It looks interesting. I think it's useful if you're using the drw.c interfaces (as a wrapper) for this. It can be found in the libsl repo: https://git.suckless.org/libsl/files.html I've had a similar project based on a stripped-down/cleanup version of stb_truetype: https://github.com/nothings/stb/blob/master/stb_truetype.h It used the drw.c interfaces and worked with dwm, dmenu and sent. Personally I lost some interest in working on this though. Thanks for sharing, -- Kind regards, Hiltjo
