zero-height fill causes 1-pixel-width leak of overlapping strokes

[jiandingzhe]

The following drawing contains two overlapping strokes and one fill between them. Specifically, the fill contains a zero-height part where corresponding stroke is purely horizontal. As a result, there will have one-pixel-width leakage of previous stroke (green) on the latter one (red).

In addition:

• If you remove the fill, there wont have leakage.

• If you extend the zero-height fill to (0,0) and (175,0), the pure-horizontal stroke on that position would also have leakage.

  nvgTranslate( nvg, float( w / 2 ), float( h / 2 ) );
  
  nvgStrokeWidth( nvg, 4.0f );
  
  // 1: stroke
  nvgBeginPath( nvg );
  nvgMoveTo( nvg, 0, 0 );
  nvgLineTo( nvg, 25, 0 );
  nvgLineTo( nvg, 50, -50 );
  nvgLineTo( nvg, 75, 0 );
  nvgLineTo( nvg, 100, 0 );
  nvgLineTo( nvg, 125, -50 );
  nvgLineTo( nvg, 150, 0 );
  nvgLineTo( nvg, 175, 0 );
  nvgStrokeColor( nvg, nvgRGBA( 0, 255, 0, 255 ) );
  nvgStroke( nvg );
  
  // 2: fill
  nvgBeginPath( nvg );
  nvgMoveTo( nvg, 25, 0 );
  nvgLineTo( nvg, 50, -50 );
  nvgLineTo( nvg, 75, 0 );
  nvgLineTo( nvg, 100, 0 );
  nvgLineTo( nvg, 125, -50 );
  nvgLineTo( nvg, 150, 0 );
  nvgFillColor( nvg, nvgRGBA( 0, 0, 255, 255 ) );
  nvgFill( nvg );
  
  // 3: stroke
  nvgBeginPath( nvg );
  nvgMoveTo( nvg, 0, 0 );
  nvgLineTo( nvg, 25, 0 );
  nvgLineTo( nvg, 50, -50 );
  nvgLineTo( nvg, 75, 0 );
  nvgLineTo( nvg, 100, 0 );
  nvgLineTo( nvg, 125, -50 );
  nvgLineTo( nvg, 150, 0 );
  nvgLineTo( nvg, 175, 0 );
  nvgStrokeColor( nvg, nvgRGBA( 255, 0, 0, 255 ) );
  nvgStroke( nvg );

[jiandingzhe]

screenshot of rendering result

[memononen]

There are problems with very thin features due to anti-aliasing algorithm. It shrinks the shape by 0.5px, and on very thin features that may flip it inside out.

If you need to make the zero height to work, you need to MSAA, and turn off the software AA in nanovg.

[jiandingzhe]

After have some look on the rendering sequence provided by NSight, I found that the last OpenGL draw call in fill command attempts to do coloring and stencil buffer clear at the same time, but the geometry is one pixel-line smaller than the rendered stencil buffer in my example, thus stencil buffer is not fully cleared and disturbs subsequent rendering.

I tried to add an extra glClear(GL_STENCIL_BUFFER_BIT) call at last of glnvg__fill function. This ensure stencil buffer is clear and it really solves this rendering glitch. However I'm not going to pull-request this change, as it looks a little bit dirty and may reduce rendering speed to some extent.

I'm wondering if it's possible to generate stencil buffers in some nicer way (e.g. by some refined bit mode), so that previous remnants would always overwritten and not disturb new drawings?

[xandramax]

This antialiasing issue can also present itself when using NVG_HOLE path winding:

https://community.vcvrack.com/t/investigating-a-rendering-error-in-rack-2-nvg-hole-layer-1/14798