<p>There is really no good way of doing this efficiently analytically for all corner cases. Most or all commercial 2D renderers that attempt to do analytic coverage calculation make predictable errors that multisampling methods do not.</p>

<p>A typical problem is two overlapping shapes that share the same edge. The common situation is that alpha channels sum up to a too thick alpha edge that aliases slightly. Or if shapes are differently colored the system confuses what color the background is. This is extremely annoying.</p>

<p><img src="https://i.sstatic.net/Tfs4k.png" alt="image"></p>

<p><strong>Image 1</strong>: The rendering engine confuses the coverage and makes a thin white outline where no outline should be.</p>

<p>Second perfect coverage amounts to box filtering. We can certainly do better. Considering that there are so many special corner cases that would require boolean operations on the shapes to do right, super sampling is still superior. In fact the coverage estimates may be used to concentrate sampling where it's most likely needed.</p>

<p>The situation could be simplified to polygons at sub pixel levels then the discrete analytical solution could be solved. But this at the expense of flexibility. For example its not out of the question that future vector systems might want to allow for variable width blurred lines which pose a problem for analytic solutions, as do other variably colored objects.</p>

<h3>How to do it analytically</h3>

<p><img src="https://i.sstatic.net/CihEg.png" alt="Analytic scene"></p>

<p><strong>Image 2</strong>: Suppose you have this scene, exploded view on right</p>

<p>Now you can not just do this analytically, each piece separately and then merge the data. Because it results in wrong data. See alpha blending would let the blue shine trough the gaps if you did so.</p>

<p>What you have to so is split the scene up so that each shape eliminates what is under the other:</p>

<p><img src="https://i.sstatic.net/rJu1X.png" alt="enter image description here"></p>

<p><strong>Image 3</strong>: You need to cut the underlying surfaces.</p>

<p>Now if everything is opaque then this is all straight forward. just calculate the area of each piece and multiply that by color and sum them together. Now you can use something like <a href="https://stackoverflow.com/questions/10039679/how-can-i-calculate-the-area-of-a-bezier-curve">this</a>.</p>

<p>This all breaks down if your individual shapes aren't opaque off course but even that can be done at some level.</p>

<p>Remember:</p>

<ul>
<li>AA calculation need to be done in linear color space, and converted back to use space.</li>
</ul>

CC BY-SA 3.0
2015-08-09T23:18:37.830Z
Say that we don't care very much about efficiency. How would we go about doing coverage calculations for boolean operations on shapes? Is that possible in general, or only for specific shapes?
John Calsbeek
CC BY-SA 3.0
2015-08-12T17:50:18.053Z
@JohnCalsbeek ok im starting to build the analytic answer, its going to take a while
joojaa
CC BY-SA 3.0
2015-08-09T21:07:03.407Z
2015-08-14T07:36:33.963Z
2017-05-23T12:39:19.850Z
joojaa
<p>Antialiasing of 2D shapes boils down to computing the fraction of a pixel that is covered by the shape. For simple non-overlapping shapes, this is not too difficult: clip the shape against the pixel rectangle and calculate the resulting shape's area. But it becomes more difficult if multiple shapes overlap the same pixel. Simply summing areas can cause the computed coverage to be too high, if it neglects the amount that one shape covers another shape. For example, see <a href="http://nothings.org/gamedev/rasterize/">the Limitations section of this article on font rendering</a>. You might also be in a situation where the two curves come from different objects with different colors (so it's not about the total coverage for the union of the two shapes, but the coverage of each one separately).</p>

<p>How would this be computed if you cared about complete accuracy? Even trickier, how do you compute coverage accurately for overlapping non-polygonal shapes like curves? Is there some point when you have no choice but to fall back to multisampling or stochastic techniques?</p>

<antialiasing><curve>
How do I accurately compute coverage of overlapping analytical curves?
John Calsbeek
# How do I accurately compute coverage of overlapping analytical curves?

(Asked by: username_0 on 2015-08-09)

Antialiasing of 2D shapes boils down to computing the fraction of a pixel that is covered by the shape. For simple non-overlapping shapes, this is not too difficult: clip the shape against the pixel rectangle and calculate the resulting shape's area. But it becomes more difficult if multiple shapes overlap the same pixel. Simply summing areas can cause the computed coverage to be too high, if it neglects the amount that one shape covers another shape. For example, see [the Limitations section of this article on font rendering](http://nothings.org/gamedev/rasterize/). You might also be in a situation where the two curves come from different objects with different colors (so it's not about the total coverage for the union of the two shapes, but the coverage of each one separately).

How would this be computed if you cared about complete accuracy? Even trickier, how do you compute coverage accurately for overlapping non-polygonal shapes like curves? Is there some point when you have no choice but to fall back to multisampling or stochastic techniques?

**Tags:** antialiasing, curve


---

## 1 answers

### Answer by username_1 on 2015-08-09. Score: 10 | Accepted answer

There is really no good way of doing this efficiently analytically for all corner cases. Most or all commercial 2D renderers that attempt to do analytic coverage calculation make predictable errors that multisampling methods do not.

A typical problem is two overlapping shapes that share the same edge. The common situation is that alpha channels sum up to a too thick alpha edge that aliases slightly. Or if shapes are differently colored the system confuses what color the background is. This is extremely annoying.

![image](https://i.sstatic.net/Tfs4k.png)

**Image 1**: The rendering engine confuses the coverage and makes a thin white outline where no outline should be.

Second perfect coverage amounts to box filtering. We can certainly do better. Considering that there are so many special corner cases that would require boolean operations on the shapes to do right, super sampling is still superior. In fact the coverage estimates may be used to concentrate sampling where it's most likely needed.

The situation could be simplified to polygons at sub pixel levels then the discrete analytical solution could be solved. But this at the expense of flexibility. For example its not out of the question that future vector systems might want to allow for variable width blurred lines which pose a problem for analytic solutions, as do other variably colored objects.

### How to do it analytically

![Analytic scene](https://i.sstatic.net/CihEg.png)

**Image 2**: Suppose you have this scene, exploded view on right

Now you can not just do this analytically, each piece separately and then merge the data. Because it results in wrong data. See alpha blending would let the blue shine trough the gaps if you did so.

What you have to so is split the scene up so that each shape eliminates what is under the other:

![enter image description here](https://i.sstatic.net/rJu1X.png)

**Image 3**: You need to cut the underlying surfaces.

Now if everything is opaque then this is all straight forward. just calculate the area of each piece and multiply that by color and sum them together. Now you can use something like [this](https://stackoverflow.com/questions/10039679/how-can-i-calculate-the-area-of-a-bezier-curve).

This all breaks down if your individual shapes aren't opaque off course but even that can be done at some level.

Remember:

* AA calculation need to be done in linear color space, and converted back to use space.

> **Comments:**
> **username_0**: Say that we don't care very much about efficiency. How would we go about doing coverage calculations for boolean operations on shapes? Is that possible in general, or only for specific shapes?  
> **username_1**: @username_0 ok im starting to build the analytic answer, its going to take a while  

---

