In draw scopes, does anyone know the cost of "cons...

# compose

[Ali Khaleqi Yekta]

In draw scopes, does anyone know the cost of "constructing and configuring a androidx.compose.ui.graphics.Paint once + using canvas.draw* " vs. "using the draw* functions and letting it figure out what cached Paint is needed, configuring it on every frame"?

[romainguy]

So in the second case you want to re-use the same Paint across multiple draw calls?

[romainguy]

Doing this means that the rendering pipeline must make copies of the (native) paint object for each draw call. So the first approach is better

[romainguy]

Whether this will actually impact performance depends a lot on what you are doing and at what frequency

[Ali Khaleqi Yekta]

In the second case, I don't interact with any Paint objects directly. The linked compose abstraction manages it automatically, which as the code shows is reusing at most two instances of Paint and setting their properties on each draw* call

[romainguy]

If it's a few draw calls, it's not a big deal

[romainguy]

If you are going to do it hundreds+ of times per frame…

[Ali Khaleqi Yekta]

Agreed. like particles, stars, etc.

[Jonathan]

It’s not clear to. Why is constructing your own Paint instance more efficient than using the DrawScope.draw*() functions when performing hundreds of draw operations per frame?

[romainguy]

Every time you modify painting parameters (let's say the color), the rendering pipeline must make a copy of the paint since rendering doesn't happen immediately

[romainguy]

If you draw with the same parameters every time, it won't cost anything