lyon

ve if all you care about is TrueType) has to be repeated over and over again for every pixel/subsample in the scene. I don't know how any non-tessellating algorithm can avoid this asymptotic problem, since if you defer all the work to the fragment shader then you have no choice but to run your expensive shader on a conservative cover area instead of only the areas that need to be expensive (i.e. edges, or curves if you're doing Loop Blinn). By contrast, traditional scanline rendering on the CPU is O(height ∗ number of curves), not counting the blitting, and forward differencing can make the work needed to be done for each curve on the scanline extremely cheap. For this reason, every non-tessellating algorithm I've seen is significantly outperformed by typical CPU renderers in practice. This is not to say that non-tessellating text renderers such as what Slug seems to be are worthless: they may be useful to avoid costly CPU/GPU synchronization if the size of the text to render is not known by the CPU, for example if it depends on the result of vertex shading for a scene. My further work on Pathfinder, should it pan out, ought to allow for more precise tessellation without significant performance cost, exploiting the fact that the shape of the traditional CPU scanline rendering algorithm can be adapted to generate triangulations on-the-fly through monotone polygon decomposition. My colleague Nical Silva's Lyon [2] shows how this idea can work, though I'm still working on adapting the technique to efficiently handle curves and high quality Levien-style antialiasing. This would eliminate the compute shader step, allowing Pathfinder to easily composite into 2D and 3D scenes as Slug can do without sacrificing performance. Bear in mind that this work is highly experimental and unfinished. [1]: http://wdobbie.com/post/gpu-text-rendering-with-vector-textu.... [2]: https://github.com/nical/lyon

pixel/subsample in the scene. I don't know how any non-tessellating algorithm can avoid this asymptotic problem, since if you defer all the work to the fragment shader then you have no choice but to run your expensive shader on a conservative cover area instead of only the areas that need to be expensive (i.e. edges, or curves if you're doing Loop Blinn). By contrast, traditional scanline rendering on the CPU is O(height ∗ number of curves), not counting the blitting, and forward differencing can make the work needed to be done for each curve on the scanline extremely cheap. For this reason, every non-tessellating algorithm I've seen is significantly outperformed by typical CPU renderers in practice. This is not to say that non-tessellating text renderers such as what Slug seems to be are worthless: they may be useful to avoid costly CPU/GPU synchronization if the size of the text to render is not known by the CPU, for example if it depends on the result of vertex shading for a scene. My further work on Pathfinder, should it pan out, ought to allow for more precise tessellation without significant performance cost, exploiting the fact that the shape of the traditional CPU scanline rendering algorithm can be adapted to generate triangulations on-the-fly through monotone polygon decomposition. My colleague Nical Silva's Lyon [2] shows how this idea can work, though I'm still working on adapting the technique to efficiently handle curves and high quality Levien-style antialiasing. This would eliminate the compute shader step, allowing Pathfinder to easily composite into 2D and 3D scenes as Slug can do without sacrificing performance. Bear in mind that this work is highly experimental and unfinished. [1]: http://wdobbie.com/post/gpu-text-rendering-with-vector-textu... [2]: https://github.com/nical/lyon