*[SOLVED]*: There is bug with `Path.op` methods (`androidx.compose.ui.graphics.Path`). The method is...

# compose

[rsktash]

[SOLVED]: There is bug with Path.op methods (androidx.compose.ui.graphics.Path).
The method is ignoring last param options. All of them difference, intersect reverseDifference doing union path

[rsktash]

[rsktash]

@jim

[rsktash]

This android view snippet

[rsktash]

This is compose view snippet

[romainguy]

@Nader Jawad

[rsktash]

I think the issue is originating from skija lib

[Nader Jawad]

Looks like you're doing the path op but drawing a different path parameter

[rsktash]

Yes I tried with all options but it is drawing with union operation

[romainguy]

Do you have the issue with Compose Desktop or on Android?

[romainguy]

If Compose Desktop it might be an issue in skija/skiko

[rsktash]

First i tested with AS preview. Now I’m testing with android device

[rsktash]

The same with android device

[rsktash]

Maybe there is issue with binding?

[dector]

I think you need to use addRect() instead of drawRect() 🙂

[Nader Jawad]

Oh that's a good point, the calls in the apply method for the path should be path operations not drawing calls as part of the drawScope receiver scope

[romainguy]

Good catch :)

[rsktash]

@dector 🙈
Thank you

[Nader Jawad]

One thing to note is that this is a good opportunity to leverage Modifier.drawWithCache as it breaks up the drawing operation into 2 steps that can be used to conditionally allocate and cache paths instead of allocating them on each draw call. Because the initial scope of drawWithCache isn't a DrawScope it makes it more difficult to call into drawing APIs instead of path operations

[rsktash]

Thank you @Nader Jawad too. I’ll try it

[rsktash]

@Daniel

[rsktash]

@Nader Jawad Is there a sample or doc for Modifier.drawWithCache

[Daniel]

@Nader Jawad @jvmusin. I've found drawWithCache super confusing

[Daniel]

I initially thought it was broken, then happened to hear in a stream (by Leland Richardson) that it only cached calls in the initial draw with cache scope, not in the drawBehind/drawWithContent calls. The documentation is not at all clear about that

[Daniel]

I also have an issue where it isn't invalidating if a state read in the cache scope is read. I'm not sure if that's intended behavior or not

[Nader Jawad]

drawWithCache does invalidate the cache on state reads as well

[Daniel]

let me try and repro and file a bug then

[Nader Jawad]

https://cs.android.com/androidx/platform/frameworks/support/+/androidx-main:compose/ui/ui/samples/src/main/java/androidx/compose/ui/samples/DrawModifierSample.kt;l=51?q=drawModifierSample%20

[Nader Jawad]

We have a few samples of the usage here. It is used a lot in the implementation of compose and simplifies a lot of remember/boilerplate code as well. The cached parameters will be reused unless either the size changed or a state parameter that is read has changed

[Daniel]

It was my mistake. I had a call to graphicsLayer higher up in the modifier chain, and I didn't realize that would interfere. Reading the docs a second time though its clear that's expected behavior

[Nader Jawad]

This should also be supported in graphicsLayer usages as well

[Daniel]

Thanks for letting me know @Nader Jawad. I filed a bug with a repro project. https://issuetracker.google.com/issues/181589173

[Nader Jawad]

Thanks! Will take a look