Antialias without MSAA

[ChengCat]

I am feeling that nanovg with a tweak mentioned in this issue looks smoother than MSAA, at least when viewed in traditional low-DPI monitors. Do you have any opinion that we support this feature in Tarp?

[mokafolio]

I will have to look into that. I don't think that this approach will work for stencil/cover approach (which is what Tarp is doing) as a stencil buffer value is either on or off. Since you can't easily read back the stencil buffer values in the shader either, I don't see how this can be easily accomplished. I'll check the linked issue later to make sure I didn't miss anything. Let me know if you have any thoughts on how this could fit into the existing tarp pipeline! Thank you!

[ChengCat]

Sorry for the late reply, I was distracted by a few other things.

Glad to see you are open with this feature, and I think you are right that this feature can't be implemented easily. nanovg does it by drawing an additional fringe (there's an article pointed out by nanovg's author: https://developer.nvidia.com/gpugems/GPUGems2/gpugems2_chapter22.html). The fringe is drawn by extending the original geometry shapes, and specifying a texture coordinate for each of the points.

For things other than arbitrary polygon clipping, nanovg can already do anti-aliasing. Anti-aliased arbitrary polygon clipping may be possible by using a framebuffer to store the alpha values of the clipping shape, in addition to the stencil buffer.

[mokafolio]

Yeah, that's what I thought. Generally speaking, it does not really fit into the flow of how tarp works. What I'd recommend to do if you need AA for now but dont want to have it on your main frame buffer is to create an offscreenbuffer that has MSAA that you draw into using tarp. Then you could use the resulting texture to draw to your main frame buffer. Hope that makes sense!

[ChengCat]

To clarify a bit, what I want is better rendering quality than MSAA, which could be important for my use case. I am trying to create a video game, in which quality of anti-alias borders could be very visible. Hope this makes sense.

I do however totally understand if you don't want to implement this feature since it takes a non-trivial amount of work. I'll wait and see, and if this is indeed very important, I would implement this myself in the future.

[ChengCat]

To clarify a bit more, nanovg also uses stencil to render non-convex polygons. The geometry need to be extended for anti-alias, but that's definitely not a complex algorithm like arbitrary polygon simplification.

Preferably, I would implement the anti-alias feature after the Vulkan backend is done. This is for (1) better understanding of the full picture when doing the implementation, (2) to minimize my cognitive context switch.

[mokafolio]

Ah I see, that makes sense. Just FYI, I put the vulkan backend on hold for now as I don't have any immediate need for it and have other more important things on my plate for now. I will most likely get back to it eventually, I just don't know when at this point in time!

[ChengCat]

I don't have an immediate need for Vulkan backend either, but I am feeling Vulkan would be an important feature for this library, and may help improve rendering performance.

No rush to it though. I'll try to coordinate with you when I start to do anything significant. :-)

[ChengCat]

There are two in-depth Hacker News threads discussing vector graphics rendering in recent few days, which I think you might be interested:

• https://news.ycombinator.com/item?id=19862748
• https://news.ycombinator.com/item?id=19871207

Regarding the antialias problem, to quote a comment from those discussions:

As far as I know, you basically get to choose two of antialiasing quality, correctness, and performance. The viable antialiasing options for vectors are:

1. Supersampling/multisampling. This is what you suggested. This provides correctness with coincident edges, but 256xAA (what analytic AA gives you) is far too slow and memory intensive to be practical if you supersample. In general practical implementations of MSAA/SSAA are limited to 16xAA or so, which is a noticeable drop in quality and in fact is still pretty slow relative to a high-quality implementation of analytic AA.

2. Analytic antialiasing. This has problems with coincident edges, but in most cases the effects are minimal. The performance and quality are excellent if implemented properly.

I generally think that analytic AA is the right tradeoff for most applications. Subtle rendering problems on coincident edges are usually a small price to pay for the excellent results, and designers can work around those issues when they come up. A 100% theoretically correct rasterizer can't exist anyway, because of floating point/fixed point precision issues among other reasons.

Tarp currently uses the supersampling/multisampling approach, which has correctness, but sub-optimal antialias quality.

The method I was suggesting in this issue is neither the two approaches listed above. It doesn't have correctness, and antialias quality is also not optimal. I am not interested in the this method any more, as it is losing on both fronts.

I am interested in experimenting with an analytic antialiasing implementation. It seems to promise perfect antialias quality and better performance, and it seems that an implementation could actually be very simple (https://github.com/linebender/piet-metal). The downside of it is that correctness is lost, and demands more of GPU hardware. I have to postpone this for some time however, because I am still working on other components of my game engine.

[mokafolio]

Sure, have a stab at it. Especially for realtime use, I doubt that you'll be able to outperform MSAA in both quality and performance. I'd love to be proven wrong, though!! :)