SOLVED There is bug with `Path op` methods `androidx compose

Question

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 · Answer

< jim>

rsktash · Answer

This android view snippet

rsktash · Answer

This is compose view snippet

romainguy · Answer

< Nader Jawad>

rsktash · Answer

I think the issue is originating from skija lib

Nader Jawad · Answer

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

rsktash · Answer

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

romainguy · Answer

Do you have the issue with Compose Desktop or on Android

romainguy · Answer

If Compose Desktop it might be an issue in skija skiko

rsktash · Answer

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

rsktash · Answer

The same with android device

rsktash · Answer

Maybe there is issue with binding

dector · Answer

I think you need to use `addRect ` instead of `drawRect ` slightly smiling face

Nader Jawad · Answer

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 · Answer

Good catch

rsktash · Answer

< dector> see no evil Thank you

Nader Jawad · Answer

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 · Answer

Thank you < Nader Jawad> too I ll try it

rsktash · Answer

< Daniel>

rsktash · Answer

< Nader Jawad> Is there a sample or doc for `Modifier drawWithCache`

Daniel · Answer

< Nader Jawad> < jvmusin> I ve found drawWithCache super confusing

Daniel · Answer

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 · Answer

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 · Answer

drawWithCache does invalidate the cache on state reads as well

Daniel · Answer

let me try and repro and file a bug then

Nader Jawad · Answer

Nader Jawad · Answer

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 · Answer

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 · Answer

This should also be supported in graphicsLayer usages as well

Daniel · Answer

Thanks for letting me know < Nader Jawad> I filed a bug with a repro project

Nader Jawad · Answer

Thanks Will take a look