4 ms·

I find it curious the number of people in this thread being amazed that high end i7 processors and graphics cards designed for gaming can passably render some t

I find it curious the number of people in this thread being amazed that high end i7 processors and graphics cards designed for gaming can passably render some text. Is there something I'm missing?

Qantourisc 11y ago
It's not so much they are amazed it capable of doing this. But more of a WOW this is fast compared to rendering theses slow PDF pages on the CPU. It's a bit like saying: wow this rocket propelled car is fast. Are we surprised it is faster ? No. Are we like: "wow we could go faster !"? Yes To be fair, I don't understand why we don't have a lib, or even this stuff build into OpenGL/Direct3D. We are doing raster work CPU's. It's relatively slow.
- corysama 11y ago
  Microsoft has Direct2D https://msdn.microsoft.com/en-us/library/windows/desktop/dd370987(v=vs.85).aspx https://msdn.microsoft.com/en-us/library/windows/desktop/dd3... Nvidia has it's nvPathRendering extension to OpenGL https://developer.nvidia.com/nv-path-rendering https://developer.nvidia.com/nv-path-rendering I'm not aware of a fully portable equivalent to either of these two libs.
vidarh 11y ago
The something you're missing is that we're used to see this done on the CPU, and it's not something CPUs are good at: Pages full of text rendered with scalable fonts involves either a huge number of bezier curves etc. or a huge number of small blits, though you can trade some of it off by spending huge amounts of memory pre-rendering and caching (but if you cache bitmaps at the character level, you will find it harder to do really nice typography - ligatures etc.). It's not that it's that amazing that it's possible on a GPU, but that it's amazing to see the difference.
- joosters 11y ago
  Sorry to sound like an old fart, but computers have been doing this for years, and no, caching rendered glyphs does not eat huge amounts of memory. e.g. RiscOS on ancient ARM processors, drawing sub-pixel anti-aliased text on a CPU that had no floating point. Even just 64kb of font cache to store the bitmaps could keep everything running blazingly fast. Of course, the font renderers have gotten smarter, and of course, screen resolutions have increased, but the difficulties inherent in font renderering are all at the small scale, where you want text to remain crisp even when using only a few pixels.
  - watmough 11y ago
    I have to quibble with blazing fast. What was the resolution on an A3000 or whatever. Pretty low. My recall was the anti-aliased text rendering was technically impressive, but practically less-so due to low-resolution. A SUN or Mac was quite a bit nicer. On the Archimedes rendering against a non-solid non-monochrome color was especially nasty. In that case, caching very expensive rendering to improve performance makes complete sense. Nice Impression summary and screenshot here. http://www.iconbar.com/forums/viewthread.php?threadid=10197 http://www.iconbar.com/forums/viewthread.php?threadid=10197 Bear in mind running on a 4 MHz ARM3 I would think. Now, with a sufficiently high-resolution display and a performant pixel shader, all the stupid caching and hinting logic can be thrown away, and effort can go instead into optimizing this technique, with no loss of generality, when rendering to arbitrary structures in the page.
    - joosters 11y ago
      Since screen resolutions have scaled far more slowly than memory sizes in the last couple of decades, surely it makes even more sense to cache font rendering nowdays? If we both agree that it was a win for low resolutions (say 640x480), back when a computer might have 2MB of RAM, surely it's far less of a cost now that we have 4k displays (only a few factors bigger) and well over 1000x the amount of memory. Just about everything in computing is a form of caching. It's rarely stupid, so throwing it out is short-sighted.
  - vidarh 11y ago
    > Sorry to sound like an old fart, but computers have been doing this for years With the CPU, yes, but not on the GPU. The point is that we've generally been limited to doing this serially, which ties into this: > and no, caching rendered glyphs does not eat huge amounts of memory It does the moment your user starts to zoom rapidly in and out like in this demo and you want smooth zooming without rendering artefacts, potentially with multiple fonts, and potentially dealing with large font sizes and multi-colour fonts. I'm an old enough fart myself to know that at least the earliest ARMs with RiscOS (as well as the Amiga's) had little enough memory/cpu bandwidth to make fast, smooth zooming of lots of text a challenge even with pre-cached font-bitmaps. And it took a long time before most systems would have enough memory to be able to treat this that casually. > Of course, the font renderers have gotten smarter, and of course, screen resolutions have increased, but the difficulties inherent in font renderering are all at the small scale, where you want text to remain crisp even when using only a few pixels. I've written terminal emulator code, and I've written GUI toolkit code several times, and text rendering speed on CPUs is still something that needs a lot of optimization to avoid it being a bottleneck. At small sizes you obviously can easily afford to cache, but then you end up having many more small blits - the overhead is still painful but for different reasons. E.g. intelligently blitting the existing window content to minimize re-rendering tends to be a major speedup vs. re-rendering every glyph even with fixed width bitmap fonts.

I find it curious the number of people in this thread being amazed that high end i7 processors and graphics cards designed for gaming can passably render some text. Is there something I'm missing?

Qantourisc 11y ago

It's not so much they are amazed it capable of doing this. But more of a WOW this is fast compared to rendering theses slow PDF pages on the CPU. It's a bit like saying: wow this rocket propelled car is fast. Are we surprised it is faster ? No. Are we like: "wow we could go faster !"? Yes To be fair, I don't understand why we don't have a lib, or even this stuff build into OpenGL/Direct3D. We are doing raster work CPU's. It's relatively slow.

corysama 11y ago
Microsoft has Direct2D https://msdn.microsoft.com/en-us/library/windows/desktop/dd370987(v=vs.85).aspx https://msdn.microsoft.com/en-us/library/windows/desktop/dd3... Nvidia has it's nvPathRendering extension to OpenGL https://developer.nvidia.com/nv-path-rendering https://developer.nvidia.com/nv-path-rendering I'm not aware of a fully portable equivalent to either of these two libs.

vidarh 11y ago

The something you're missing is that we're used to see this done on the CPU, and it's not something CPUs are good at: Pages full of text rendered with scalable fonts involves either a huge number of bezier curves etc. or a huge number of small blits, though you can trade some of it off by spending huge amounts of memory pre-rendering and caching (but if you cache bitmaps at the character level, you will find it harder to do really nice typography - ligatures etc.). It's not that it's that amazing that it's possible on a GPU, but that it's amazing to see the difference.

joosters 11y ago
Sorry to sound like an old fart, but computers have been doing this for years, and no, caching rendered glyphs does not eat huge amounts of memory. e.g. RiscOS on ancient ARM processors, drawing sub-pixel anti-aliased text on a CPU that had no floating point. Even just 64kb of font cache to store the bitmaps could keep everything running blazingly fast. Of course, the font renderers have gotten smarter, and of course, screen resolutions have increased, but the difficulties inherent in font renderering are all at the small scale, where you want text to remain crisp even when using only a few pixels.
- watmough 11y ago
  I have to quibble with blazing fast. What was the resolution on an A3000 or whatever. Pretty low. My recall was the anti-aliased text rendering was technically impressive, but practically less-so due to low-resolution. A SUN or Mac was quite a bit nicer. On the Archimedes rendering against a non-solid non-monochrome color was especially nasty. In that case, caching very expensive rendering to improve performance makes complete sense. Nice Impression summary and screenshot here. http://www.iconbar.com/forums/viewthread.php?threadid=10197 http://www.iconbar.com/forums/viewthread.php?threadid=10197 Bear in mind running on a 4 MHz ARM3 I would think. Now, with a sufficiently high-resolution display and a performant pixel shader, all the stupid caching and hinting logic can be thrown away, and effort can go instead into optimizing this technique, with no loss of generality, when rendering to arbitrary structures in the page.
  - joosters 11y ago
    Since screen resolutions have scaled far more slowly than memory sizes in the last couple of decades, surely it makes even more sense to cache font rendering nowdays? If we both agree that it was a win for low resolutions (say 640x480), back when a computer might have 2MB of RAM, surely it's far less of a cost now that we have 4k displays (only a few factors bigger) and well over 1000x the amount of memory. Just about everything in computing is a form of caching. It's rarely stupid, so throwing it out is short-sighted.
- vidarh 11y ago
  > Sorry to sound like an old fart, but computers have been doing this for years With the CPU, yes, but not on the GPU. The point is that we've generally been limited to doing this serially, which ties into this: > and no, caching rendered glyphs does not eat huge amounts of memory It does the moment your user starts to zoom rapidly in and out like in this demo and you want smooth zooming without rendering artefacts, potentially with multiple fonts, and potentially dealing with large font sizes and multi-colour fonts. I'm an old enough fart myself to know that at least the earliest ARMs with RiscOS (as well as the Amiga's) had little enough memory/cpu bandwidth to make fast, smooth zooming of lots of text a challenge even with pre-cached font-bitmaps. And it took a long time before most systems would have enough memory to be able to treat this that casually. > Of course, the font renderers have gotten smarter, and of course, screen resolutions have increased, but the difficulties inherent in font renderering are all at the small scale, where you want text to remain crisp even when using only a few pixels. I've written terminal emulator code, and I've written GUI toolkit code several times, and text rendering speed on CPUs is still something that needs a lot of optimization to avoid it being a bottleneck. At small sizes you obviously can easily afford to cache, but then you end up having many more small blits - the overhead is still painful but for different reasons. E.g. intelligently blitting the existing window content to minimize re-rendering tends to be a major speedup vs. re-rendering every glyph even with fixed width bitmap fonts.