Ganesh vs. Raster AA differences with off-pixel rendering.

[Corey Lucier]

Can someone enlighten as to why we see a difference in the following scenario between Ganesh and CPU rendering backends?

Setup:

Render a white rectangle on top of a red rectangle and scale the canvas such that the rectangles would be placed off-pixel. 

Ensure the white rectangle and red rectangle are identical in height and y position.

As expected since both are off-pixel the semi-transparent AA pixels of the off-pixel edges for both the white and red rectangle are visible. Note the hairline "pink" edges where the white rectangle overlaps the red.  While this is sub-optimal it's the "expected" behavior of most vector renderers in this situation - a fact of life if you will.  Obviously if pixel snapped the hairlines aren't visible.

If instead you render with Ganesh you don't see the artifact, and oddly you see the white rectangle's AA pixels blending directly with the background pixels, in this case I've made the background blue and zoomed in with a loupe ... so the red rectangle behind seems to be full occluded before rasterization.

Basically this is only a problem because switching between raster and GPU Skia shouldn't suddenly make artifacts disappear/re-appear in this scenario - but perhaps another "fact of life" ?

-C

[Cary Clark]

just to be clear does this illustrate your concern? https://fiddle.skia.org/c/@redwhiteonblue

--
You received this message because you are subscribed to the Google Groups "skia-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to skia-discuss+unsubscribe@googlegroups.com.
To post to this group, send email to skia-d...@googlegroups.com.
Visit this group at https://groups.google.com/group/skia-discuss.
For more options, visit https://groups.google.com/d/optout.

[Corey Lucier]

No doesn't seem to, will mess around a bit.  

Now I'm not clear as to why I can't repro easily with fiddle.

[Corey Lucier]

Ok here this fiddle is closer...

https://fiddle.skia.org/c/e337db1b3d4bc0ca61001d9e9de66d11

But I can't seem to repro a difference in Ganesh vs. CPU like I can in Chrome (where I first noticed the discrepancy):

See this CodePen - it shows the AA edges in Safari, but not in Chrome (default)  60.0.3112.101

If I change GPU Rasterization in about:flags to "Disabled" you see the AA edges appear!

[Corey Lucier]

Sorry - https://fiddle.skia.org/c/633aa43f58e312a374a7387cd65096fd

[Yuqian Li]

It seems to me that the artifact should be related to blending. I'm not an expert on that. But I probably can explain why you can't reproduce the difference in Skia fiddler, but you can see it in Chrome.

The CPU backend is evolving and there's a guard flag in Chrome that stops us using the newest CPU path renderer because we haven't rebase all the Chrome tests yet. That says, Skia fiddler is using the newest CPU renderer, but the Chrome is now using an older CPU renderer.

[Corey Lucier]

Well it's with GPU enabled that the discrepancy occurs.

[Yuqian Li]

Right, GPU is probably evolving even faster than the CPU backend so I wouldn't be surprised if there are more flags on the GPU side that make Chrome's Ganesh behave differently from the Skia fiddler's Ganesh.

BTW, the new CPU path renderer isn't turned on for convex paths by default in any cases so any difference on convex paths is probably indeed just caused by GPU changes.

On Tue, Aug 29, 2017 at 10:20 AM, Corey Lucier <corey....@gmail.com> wrote:

Well it's with GPU enabled that the discrepancy occurs.

--

[Brian Salomon]

Corey, I don't see the link to the codepen page. It's possible the site is triggering Chrome to use MSAA in which case the edge of the red rectangle wouldn't be seen.

Brian

On Tue, Aug 29, 2017 at 10:20 AM Corey Lucier <corey....@gmail.com> wrote:

Well it's with GPU enabled that the discrepancy occurs.

--

You received this message because you are subscribed to the Google Groups "skia-discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to skia-discuss...@googlegroups.com.

[Corey Lucier]

I am batting 1000 today with links:

https://codepen.io/anon/pen/GvYEzB

[Shawn Riordan]

Do you see a black crack in this rendering with ganesh?:

https://fiddle.skia.org/c/804eb689d7a0d73491d16a5fb17d8f4b

[Shawn Riordan]

The reason I ask, is that I might know the answer.

During the rasterization process, there are two types of alpha.  The opacity specified along with the color (alpha) and the opacity based on anti aliasing.  I think the second one is called "shape(?)"

It may be that the hardware, or the software driver, are batching the drawing of several shapes together.  Storing and resolving alpha seperate from shape.  Until it commits the batch.   In this strategy, there would be no pink halo because the white pixels would completely replace the red pixels.  Since the white pixels had an alpha of 1.0. This would be done without consideration of opacity due to shape.  That consideration would be implemented afterwards.  Blending the white with the background blue.

This is done to remove the crack problem illustrated in the fiddle I posted.

If ganesh doesn't get rid of the crack, then my guess could be wrong.

On Tuesday, August 29, 2017 at 5:20:21 AM UTC-7, Corey Lucier wrote:

[Dean McNamee]

On Wed, Aug 30, 2017 at 6:46 AM, Shawn Riordan <craste...@gmail.com> wrote:

The reason I ask, is that I might know the answer.

During the rasterization process, there are two types of alpha.  The opacity specified along with the color (alpha) and the opacity based on anti aliasing.  I think the second one is called "shape(?)" 

It may be that the hardware, or the software driver, are batching the drawing of several shapes together.  Storing and resolving alpha seperate from shape.  Until it commits the batch.   In this strategy, there would be no pink halo because the white pixels would completely replace the red pixels.  Since the white pixels had an alpha of 1.0. This would be done without consideration of opacity due to shape.  That consideration would be implemented afterwards.  Blending the white with the background blue.

This is done to remove the crack problem illustrated in the fiddle I posted.

If ganesh doesn't get rid of the crack, then my guess could be wrong.

I believe what you're describing is actually sort of a bug (okay, an implementation compromise) of almost all modern vector renders in regards to alpha being used for both opacity and "coverage".  This leads to a fundamental problem often called "conflation".  See for example:

"4.1.2 Conflation Avoidance" in http://developer.download.nvidia.com/devzone/devcenter/gamegraphics/files/opengl/gpupathrender.pdf

I think it's actually discussed in the original Porter Duff paper as "correlated mattes": https://keithp.com/~keithp/porterduff/p253-porter.pdf

Another reference where conflation is discussed in this context is: http://w3.impa.br/~diego/publications/GanEtAl14.pdf

I believe Skia's been doing some work lately on rendering with separate coverage and alpha.

 

On Tuesday, August 29, 2017 at 5:20:21 AM UTC-7, Corey Lucier wrote:

Can someone enlighten as to why we see a difference in the following scenario between Ganesh and CPU rendering backends?

Setup:

Render a white rectangle on top of a red rectangle and scale the canvas such that the rectangles would be placed off-pixel. 

Ensure the white rectangle and red rectangle are identical in height and y position.

As expected since both are off-pixel the semi-transparent AA pixels of the off-pixel edges for both the white and red rectangle are visible. Note the hairline "pink" edges where the white rectangle overlaps the red.  While this is sub-optimal it's the "expected" behavior of most vector renderers in this situation - a fact of life if you will.  Obviously if pixel snapped the hairlines aren't visible.

If instead you render with Ganesh you don't see the artifact, and oddly you see the white rectangle's AA pixels blending directly with the background pixels, in this case I've made the background blue and zoomed in with a loupe ... so the red rectangle behind seems to be full occluded before rasterization.

Basically this is only a problem because switching between raster and GPU Skia shouldn't suddenly make artifacts disappear/re-appear in this scenario - but perhaps another "fact of life" ?

-C

--
You received this message because you are subscribed to the Google Groups "skia-discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to skia-discuss+unsubscribe@googlegroups.com.

[Hal Canary]

On Aug 30, 2017 12:47 AM, "Shawn Riordan" <craste...@gmail.com> wrote:

During the rasterization process, there are two types of alpha.  The opacity specified along with the color (alpha) and the opacity based on anti aliasing.  I think the second one is called "shape(?)"

Sometimes called “coverage”.

[Greg Daniel]

So during the actual rendering of a primitive, we keep track alpha and coverage separately and only conflate the two at the end when writing out the dst color. We combine coverage into the blended color with the following formula: ColorFinal = Cov * Blend(Src, dst) + (1 - Cov) * dst, where Blend is some blend formula combining the src and dst color.

With MSAA the coverage inherently is kept separate from the alpha via the samples (until it is resolved and then alpha and coverage are conflated again).

--

You received this message because you are subscribed to the Google Groups "skia-discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to skia-discuss...@googlegroups.com.

[Brian Salomon]

We keep alpha and coverage separate during the rasterization, clipping, and blending of a single primitive (rect, path, etc) but they are then conflated when written into the destination buffer. Thus overlapping or abutting primitives exhibit conflation. The exception is when using MSAA where subsampling is used in place of fractional pixel coverage.

Brian

To unsubscribe from this group and stop receiving emails from it, send an email to skia-discuss...@googlegroups.com.

To post to this group, send email to skia-d...@googlegroups.com.
Visit this group at https://groups.google.com/group/skia-discuss.
For more options, visit https://groups.google.com/d/optout.

--

You received this message because you are subscribed to the Google Groups "skia-discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to skia-discuss...@googlegroups.com.

[Shawn Riordan]

Does CPU rendering support MSAA?

[Mike Reed]

Nope, never tried.

To unsubscribe from this group and stop receiving emails from it, send an email to skia-discuss+unsubscribe@googlegroups.com.