puzzle challenge

[sha...@infograph.com]

I have a use case that is difficult to implement in Skia.   PDF files have these concepts called transparency groups. Or just "group."  Where there are two flags. Isolate and knockout.  One flag controls whether or not a blendmode should apply within the drawing instructions inside the group.  While the other flag controls whether or not to apply the blendmode to the final result of all the calls.  (sort of like a Skia layer, with a blendmode on it's paint)

Between these two flags, there are 4 combinations.  The sticky one is when you say: don't apply blendmode within group, but apply to result.  AND there is more than one blendmode inside the group.

For example, the attached PNG is the result of a group that said:

- draw a thick red line with multiply blendmode.

- draw a thick blue line with screen blendmode.

The option to not apply blendmodes within a group, means that the blue line overwrites the pixels generated by the red line, rather than mixing together in a screened purple.  The final result of the group contains some pixels that should multiply and some that should screen.  Which isn't something a Skia layer can do.  So, in Skia, I am guessing they have to be two separate layers.

I have found a way to do it, in Skia, but it requires copying the geometry of the later layers into the earlier layers, with the kDestOut blendmode.  So that it can erase those pixels from the earlier layers.  Here is my solution:

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

But I was wondering if anyone had any other, better, ideas on how to handle such a scenario?

My solution increases the amount of data and rendering that has to happen.

[Shawn Riordan]

One way, I guess, would be to a series of off-screen n32 surfaces.  Then walk backwards through the series and draw the snapshot image against all it's predecessors, using the destination out blendmode.   Then draw each image with the appropriate blendmode.  I don't know if that would be faster.

Meanwhile, I have found another wrinkle or two.  Since transparency group definitions can contain references to other defined transparency groups -- and those groups can have their own combination of isolate and knockout flags -- things get even more complicated.  Also, you can specify a blendmode ahead of a request to draw a transparency group; and that alters the output too.   So, for example, a square could be drawn with multiply, inside a transparency group.  Which is preceded by difference.  The resulting pdf rendering includes both blendmodes happening.  Which is impossible to do with nested layers.  It has to be series.  But the problem with series is that only one image in the series knows which pixels to apply to.  Gah!

I am contemplating a solution that involves copying the background pixels from the canvas, into the off-screen image / layer.   Is there an efficient way to do that?

[Cary Clark]

Here's a fiddle that saves the current background pixels from the canvas into an off-screen layer.

fiddle.skia.org/c/@saveLayerWithPrevious

--
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.

[Cary Clark]

Oops, meant https://fiddle.skia.org/c/@saveLayerInitWithPrevious

Thanks, Ben!

[Shawn Riordan]

Oh, that is great, thanks!

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

[sha...@infograph.com]

Was that a feature added in a recent version of Skia?

My, older, version doesn't have that flag.  Mine looks like this:

enum {

        kIsOpaque_SaveLayerFlag         = 1 << 0,

        kPreserveLCDText_SaveLayerFlag  = 1 << 1,

#ifdef SK_SUPPORT_LEGACY_CLIPTOLAYERFLAG

        kDontClipToLayer_Legacy_SaveLayerFlag = kDontClipToLayer_PrivateSaveLayerFlag,

#endif

    };

    typedef uint32_t SaveLayerFlags;

Also, I noticed that the save layer record has an image filter variable called fBackdrop.

What is that used for? Could that be used for copying pixels from destination into layer?

On Wednesday, June 14, 2017 at 6:47:31 AM UTC-7, Cary Clark wrote:

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

[Cary Clark]

Here's some work-in-progress documentation that may help:  https://skia.org/user/api/bmh_SkCanvas?cl=9919#SaveLayerRec

the links don't quite work yet, so you may need to scroll up a bit to find the current info.

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

[sha...@infograph.com]

Thanks, but what about the question?  Is saving the pixels from the destination into the layer a recent feature?  Was there no way to do it before?

[Cary Clark]

Looks like it was added in response to this feature request: https://bug.skia.org/4884

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

[Mike Reed]

I am tasked with trying to add Isolate / Knockout as orthogonal features to layers (no code to show for it yet). The current backdrop filter is certainly suggestive of how I will likely plumb these new group modes into the code.

[Shawn Riordan]

Mike, did you get my email a week ago?

[Shawn Riordan]

Is Mike on vacation?

On Thursday, June 8, 2017 at 10:15:17 AM UTC-7, sha...@infograph.com wrote:

[Mike Reed]

I am imaging the same technique : making a copy of the background.

On Tue, Jun 13, 2017 at 11:07 PM, Shawn Riordan <craste...@gmail.com> wrote:

--
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.