The problem here is that you are not choosing based on knowing how the render pipeline is implemented in these tools and how it would work with your usage of it.

You can do a couple days to a week of reading to understand the fundamentals once and then you will actually know what you are doing.

It is not proper to choose things on “battle tested” or other meaningless words

▲

appplication 2 hours ago | parent [-]

I think in light of the fact that OP included exactly to what they are trying to do, this comment would be helpful to include a more concrete recommendation.

It’s easy to hand wave and say “this wouldn’t be an issue if you knew what you were doing”, but that indeed is the problem.

	▲	ozgrakkurt an hour ago \| parent [-]
		This is mainly from my experience developing storage engines using datafusion/polars or arrow2/arrow-rs or rocksdb-msbx. I was changing between them and searching for comparisons online. This ended up being a massive amount of lost time because all of those choices became crystal clear when I actually roughly understood what these libraries were doing. And actually learning the thing didn’t take as much time as writing code for comparison and discarding it or doing dead-end web searches. Recently had a similar experience trying to learn dwarf parsing from LLMs or searching for existing code. Then I just realised that reading the spec is by far the most efficient way to understand it. I am guessing same principle applies to text rendering because I got the same vibe when watching Raph Levien talk about it on some video. Searching online to read some “industry-standard” “tried and true” etc. Comments is a big sign that it might be better read some actual source about the topic imo. It doesn’t even take that much time to read a textbook even.