8 ms·

Hmm, I do wonder why would a terminal use so much GPU ressources. Maybe it gets better with reducing scrollback? Seems extreme anyway.

goldenkey 5y ago
Caching glyphs, into a texture. Then they don't need to be re-rendered and can just be copied.
- jstimpfle 5y ago
  Let's say 512 glyphs should be a pretty conservative upper bound for normal usage. Just pulling this number out of thin air, but I assume it's reasonable. normal glyphs should be about 100-400 pixels (20x20), for 8-bit grayscale that means 2MB of texture cache should be plenty for normal use. Multiply by 3 if you want to support subpixel rendered glyphs, that still leaves us with a very comfortable upper bound of 6MB. Note that optionally you can keep the glyphs on CPU memory as opposed to GPU memory, and just push the needed data in a streaming fashion to the GPU for each frame. Since there is no texture filtering for fonts (GL_NEAREST for OpenGL), no need to create a font-atlas and no needed for complicated font atlas packing. Glyph data can be allocated in a simple 1-dimensional space, and streaming a glyph's data up is just a matter of bumping a pointer and a single memcpy.
  - goldenkey 5y ago
    > 512 glyphs You're forgetting about colored glyphs. Although a fragment shader should be able to deal with that, shouldn't it?
    - jstimpfle 5y ago
      One typical approach is that glyphs are rastered (e.g. by Freetype) as 8-bit grayvalues. Basically Alpha channel if you will. You can add RGB color channels from there and blit RGBA with Alpha blending enabled. Not sure if there are finer points to consider here, it's what I've always done and it works for me. Perhaps less used, and becoming less and less relevant as higher DPI screens are becoming common: With subpixel-rasterized glyphs, you get RGB channel output from the font rasterizer instead of the Alpha channel. These are properly balanced values that are arranged to appear as "white" pixels to most viewers - the idea is that this increases the perceived horizontal resolution by a factor of up to 3. Not sure how to add color to these, maybe just multiplying each component with the respective component of a text color RGB value would work. In any case, if you have a 4K screen full of flickering glyphs that need to be of varying colors and backgrounds, that might indeed indicate a GPU approach. On the other hand, nobody is getting value of flickering glyphs, so CPU rasterization with some rate limiting would be just as good in these situations, practically speaking.

goldenkey 5y ago

Caching glyphs, into a texture. Then they don't need to be re-rendered and can just be copied.

jstimpfle 5y ago
Let's say 512 glyphs should be a pretty conservative upper bound for normal usage. Just pulling this number out of thin air, but I assume it's reasonable. normal glyphs should be about 100-400 pixels (20x20), for 8-bit grayscale that means 2MB of texture cache should be plenty for normal use. Multiply by 3 if you want to support subpixel rendered glyphs, that still leaves us with a very comfortable upper bound of 6MB. Note that optionally you can keep the glyphs on CPU memory as opposed to GPU memory, and just push the needed data in a streaming fashion to the GPU for each frame. Since there is no texture filtering for fonts (GL_NEAREST for OpenGL), no need to create a font-atlas and no needed for complicated font atlas packing. Glyph data can be allocated in a simple 1-dimensional space, and streaming a glyph's data up is just a matter of bumping a pointer and a single memcpy.
- goldenkey 5y ago
  > 512 glyphs You're forgetting about colored glyphs. Although a fragment shader should be able to deal with that, shouldn't it?
  - jstimpfle 5y ago
    One typical approach is that glyphs are rastered (e.g. by Freetype) as 8-bit grayvalues. Basically Alpha channel if you will. You can add RGB color channels from there and blit RGBA with Alpha blending enabled. Not sure if there are finer points to consider here, it's what I've always done and it works for me. Perhaps less used, and becoming less and less relevant as higher DPI screens are becoming common: With subpixel-rasterized glyphs, you get RGB channel output from the font rasterizer instead of the Alpha channel. These are properly balanced values that are arranged to appear as "white" pixels to most viewers - the idea is that this increases the perceived horizontal resolution by a factor of up to 3. Not sure how to add color to these, maybe just multiplying each component with the respective component of a text color RGB value would work. In any case, if you have a 4K screen full of flickering glyphs that need to be of varying colors and backgrounds, that might indeed indicate a GPU approach. On the other hand, nobody is getting value of flickering glyphs, so CPU rasterization with some rate limiting would be just as good in these situations, practically speaking.