https://kotlinlang.org logo
Title
t

theapache64

04/10/2021, 11:32 AM
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)
)
cc @Igor Demin
i

Igor Demin

04/10/2021, 11:44 AM
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.
t

theapache64

04/10/2021, 11:44 AM
Okay. Got it. Thanks 🙇‍♂️
o

orangy

04/10/2021, 11:46 AM
IntOffset
&
IntSize
are inline classes, so no object is created at all. It’s just Long value all the way
👍 2
t

theapache64

04/10/2021, 11:47 AM
@orangy Ohhh, that's cool. Next time I'll check the source before asking question here 😬
o

orangy

04/10/2021, 11:47 AM
But there is small penalty to pack two ints into a Long, but I doubt anyone will notice it 🙂
t

theapache64

04/10/2021, 11:49 AM
one line less is good, right? 😜
o

orangy

04/10/2021, 11:51 AM
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.
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.
t

theapache64

04/10/2021, 11:53 AM
Understood. Thanks for ur valuable comments @orangy @Igor Demin
n

Nader Jawad

04/13/2021, 8:41 PM
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
🆗 1
It's an ideal place to reuse path objects, create gradients that rely on the known size in advance or caching stroke parameters
👍 1