4 ms·

If I understand correctly the second link is basically an extension of Loop-Blinns implicit curve approach with vector textures in order to find the winding cou

If I understand correctly the second link is basically an extension of Loop-Blinns implicit curve approach with vector textures in order to find the winding counter for each fragment in one pass. >> Slug only needs to render a quad for each glyph. I don't know how many glyphs you want to render (to the point that there are so many that you can't read them anymore), but a modern GPU s are heavily optimized for triangle throughput. So 2 or 20 triangles per glyph makes only a little difference. The bigger problem is usually the sample fill rate and memory bandwidth (especially if you have to write to pixels more than once). I have been eying the scanline-intersection-sort approach (your third link) too. Sadly they have no answer to path stroking (same as everybody else) and it also requires an efficient sorting algorithm for the GPU (implementations of such are hard to come by outside of CUDA, as you mentioned).

vg_head 6y ago
Indeed, most techniques that target the GPU have no response to stroking, they recommend generating paths beforehand so that it looks like it's stroked. And yes, the number of triangles doesn't really make a difference in general, but in Slug's paper they say: "At small font sizes, these triangles can become very tiny and decrease thread group occupancy on the GPU, reducing performance" I'm not experienced enough to say how true that is/how much of a difference it makes. > If I understand correctly the second link is basically an extension of Loop-Blinns implicit curve approach with vector textures in order to find the winding counter for each fragment in one pass. I've read the paper, but to be honest it's a bit over my head right now, but AFAIK MPVG is an extension to this [1], which looks like it's an extension to Loop-Blinn itself, so I think you're right. [1] "Random-Access Rendering of General Vector Graphics" http://hhoppe.com/ravg.pdf http://hhoppe.com/ravg.pdf

vg_head 6y ago

Indeed, most techniques that target the GPU have no response to stroking, they recommend generating paths beforehand so that it looks like it's stroked. And yes, the number of triangles doesn't really make a difference in general, but in Slug's paper they say: "At small font sizes, these triangles can become very tiny and decrease thread group occupancy on the GPU, reducing performance" I'm not experienced enough to say how true that is/how much of a difference it makes. > If I understand correctly the second link is basically an extension of Loop-Blinns implicit curve approach with vector textures in order to find the winding counter for each fragment in one pass. I've read the paper, but to be honest it's a bit over my head right now, but AFAIK MPVG is an extension to this [1], which looks like it's an extension to Loop-Blinn itself, so I think you're right. [1] "Random-Access Rendering of General Vector Graphics" http://hhoppe.com/ravg.pdf http://hhoppe.com/ravg.pdf