Would it be better If I move `IntOffset` or `IntS...

# compose-desktop

[theapache64]

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

[theapache64]

cc @Igor Demin

[Igor Demin]

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.

[theapache64]

Okay. Got it. Thanks 🙇‍♂️

[Igor Demin]

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

[orangy]

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

[theapache64]

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

[orangy]

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

[theapache64]

one line less is good, right? 😜

[orangy]

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.

[orangy]

Also, when you will have floorBrick.image instead of single brickPng consider using image slices instead of different images. Using same texture repeatedly is much more efficient on GPU, so use image packing systems for this.

[theapache64]

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

[Nader Jawad]

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

[Nader Jawad]

It's an ideal place to reuse path objects, create gradients that rely on the known size in advance or caching stroke parameters