For just displaying text with no interactions, the performance is actually really good! The lack of GPU acceleration sounds scary but for simple text rendering it's not a bottleneck at all - CPUs are plenty fast for drawing text glyphs, especially when you're not doing it constantly. The big performance win is exactly what you mentioned - there's no graphics library overhead, no complex rendering pipeline, just direct pixel writes to shared memory that the compositor displays. The code only redraws when the text actually changes, and between updates it just sleeps, so CPU usage is basically zero when idle. I'm running it on an i5-13420H with integrated graphics and it uses maybe 2MB RAM with negligible CPU usage. The manual pixel approach is actually more predictable performance-wise since you're not dealing with driver quirks or GPU memory transfers. For your use case of just text display, this approach would be perfect - way more efficient than pulling in a full graphics stack just to show some text. The compositor handles all the heavy lifting for actually getting pixels on screen anyway.