4 ms·

When making my own text editor the text rendering was the bottleneck. I used web canvas fillText for text rendering. Tried to make my own text render using bitm

by z3t4 2y ago

When making my own text editor the text rendering was the bottleneck. I used web canvas fillText for text rendering. Tried to make my own text render using bitmaps but couldn't beat the "native" text rendering. So I wonder if it would get any faster with this method in webGL. For example re-parsing the whole file so that the editor can get a semantic understanding of the code - is many times faster then rendering the text. And I discovered that coding with 240 fps feels very nice! When you push a key and the you can see the result the very next frame.

dahart 2y ago
Browser engines are definitely highly optimized at text rendering, and they do cache the results of text renders and turn them into bitmaps that get blitted, so it’s not surprising it can be hard to beat even by using bitmaps, especially if you let it’s caching mechanism dominate the render time. Some things the browser engines will pay close attention to is storage layout, cache alignment, and cache line size, which is a fancy way of saying that not all bitmap renders are the same; their bitmap renderer might be faster than my naive bitmap renderer if I don’t pay attention to the hardware details. The actual rendering part of fillText() isn’t that fast though, so you probably can beat it with your own bitmaps if you were to render a different full screen of text every frame, which would undermine the bitmap caching mechanism. I’m not sure, but it might help to vary the text style every frame too; I’m not sure if the engines build font atlases on the fly… they might, in which case defeating the cache would be using enough different styles to churn through several gigabytes of image cache. Another thing to pay attention to is whether you’re rendering text to a buffer that then needs to be copied to the frame buffer, or whether you’re rendering directly to the frame buffer. Avoiding the round-trip through memory, if you can, will be quite a bit faster. The technique in the article might be best for things like debug text overlays on top of a game. If you need to display a handful of values and watch them change, this shader technique can be very fast.

by z3t4 2y ago

dahart 2y ago

Browser engines are definitely highly optimized at text rendering, and they do cache the results of text renders and turn them into bitmaps that get blitted, so it’s not surprising it can be hard to beat even by using bitmaps, especially if you let it’s caching mechanism dominate the render time. Some things the browser engines will pay close attention to is storage layout, cache alignment, and cache line size, which is a fancy way of saying that not all bitmap renders are the same; their bitmap renderer might be faster than my naive bitmap renderer if I don’t pay attention to the hardware details. The actual rendering part of fillText() isn’t that fast though, so you probably can beat it with your own bitmaps if you were to render a different full screen of text every frame, which would undermine the bitmap caching mechanism. I’m not sure, but it might help to vary the text style every frame too; I’m not sure if the engines build font atlases on the fly… they might, in which case defeating the cache would be using enough different styles to churn through several gigabytes of image cache. Another thing to pay attention to is whether you’re rendering text to a buffer that then needs to be copied to the frame buffer, or whether you’re rendering directly to the frame buffer. Avoiding the round-trip through memory, if you can, will be quite a bit faster. The technique in the article might be best for things like debug text overlays on top of a game. If you need to display a handful of values and watch them change, this shader technique can be very fast.