Would it be better If I move

IntOffset

or

IntSize

(object creation) to outside the

DrawScope

? I mean, will there any notable performance difference if I move these measurement classes outside the

DrawScope

drawImage(
    image = R.graphics.brickPng,
    dstOffset = IntOffset(floorBrick.x, floorBrick.y), // or should I call `floorBrick.intOffset?` (where intOffset created only one time)
)

Modern GC should work fine when we create many short-living small objects in a short period of time (on Android probably too, there was some changes in GC in last versions) So your don't need to move IntOffset outside of DrawScope.

Okay. Got it. Thanks 🙇‍♂️

Food for thought: https://softwareengineering.stackexchange.com/questions/149563/should-we-avoid-object-creation-in-java https://proandroiddev.com/collecting-the-garbage-a-brief-history-of-gc-over-android-versions-f7f5583e433c

IntOffset

&

IntSize

are inline classes, so no object is created at all. It’s just Long value all the way

@orangy Ohhh, that's cool. Next time I'll check the source before asking question here 😬

But there is small penalty to pack two ints into a Long, but I doubt anyone will notice it 🙂

one line less is good, right? 😜

It depends 🙂 At 60fps your game have only 16ms for each frame, so in gamedev it’s a usual thing to carefully spend this very tight budget. If your map is static and never changes, consider caching everything you can.

Understood. Thanks for ur valuable comments @orangy @Igor Demin

Yes a majority of the APIs leveraged in DrawScope, (Offset/Size/Color) are inline classes. brush and stroke parameters are not however so it would be encouraged to cache those instances for performance conscious code. Consider usage of Modifier.drawWithCache to allocate and cache these objects in a lambda scope that can be referenced within the corresponding onDraw block. These caches will be updated on size changes or state invalidations made to reads within the cache block