So we had some setbacks with the font manager. It turns out we need all kind of different font libraries, and they are not interchangeable. So what we've done now is have a generic font-manager that uses fontkit / freetype to load fonts into FontInfo structures. These structures can be used to actually load fonts in the correct libraries. Sometimes we get lucky, and can use with an already loaded font, as it is represented as a slice of bytes, but not always.

So at this point the fontmanager is kinda dealing with fonts, but not quite where we want it to be. At least for now we can skip this step and still have some kind of entrypoint for fontmanaging.

Right now we are working on the rendering (the thing i wanted to do last month, before all the font-yak-shaving stuff). We got all the rendering stuff working again, and we want to do two things: 1. Update the renderer to render stuff better. 2. Setup a new renderer that actually works as a render pipeline.

The first thing is the easiest, because we can just hack away in the existing code. But we know this will not be the final code anyway. The second things, writing a new renderer, will be harder. First, we need to write up some specification and think about how the renderer would look like, how all things would be connected and how we can do certain things at certain times in the life of a page. Writing the renderer pipeline itself isn't THAT complicated, but writing a FAST pipeline is.. most of the complexity will be in the optimization of all and trying to minimize the amount of work we actually need to do during a frame rendering.

We've been reading a lot about render pipelines, and though they work differently, they are all somewhat similar in setup. There is currently no reason to deviate from that architecture for now. By setting up some smaller experiments we will try and get the whole pipeline in a proof-of-concept style functional.