Hi everyone! Is there a way to reuse the content of a Canvas component ? Canvas redraws fully at each re-composition. How should I proceed if I wanted to draw above currently drawn content and clear the canvas on-demand ? I am trying to make an oscilloscope-like gui from a stream of audio data. I want to draw the new content acquired between each animation frames (web lingo, sorry) and maybe clip/move the old content. Should I use an off-screen canvas ?

You can just use a Canvas. Compose is optimized to redraw components when the input data changes. So it only makes sense to redraw anything when it is changed. So you do not need to redraw every frame. In you case the input would be the audio data. So just use a mutableState variable that get updated every time you have new data.

I'm sort of doing that in https://github.com/joreilly/chip-8 ....the "emulator" (in shared KMP code) is generating "display data" which it's passing back to UI and then using Compose Canvas API to render

@Timo Drick I don't get it. My audio signals are real-time. Only the last 16ms (considering the display refresh rate is 60Hz) of my audio data might be new. I don't want to redraw anything drawn before those last 16ms. I just want to move what I've drawn before. If I had to redraw all the data of all my channels, my application would be really slow.

Ok i see. No i don't think this is possible. You have to redraw every thing. But it is very fast. So you could just save the data in a variable and redraw anything.

Yeah I think this is what I have to resort to. But I can't find what class from the low-level Compose I have to use.

Drawing into a bitmap is independent of Compose.

Android supports all of AWT ?

Some thing like this:

val bitmap = Bitmap.createBitmap(width, height, Bitmap.Config.ARGB_8888)
val canvas = Canvas(bitmap)
canvas.drawLines....

But

androidx.compose.ui.graphics.Canvas

doesn't seem to have a way to move pixels or be cleared...

Yea you have to redraw everything. Every time it is rendered

I am quite sure that redrawing a 5 seconds window of 16 channels of 44kHz audio every 16 ms will not work... 🙂

it depends on how many lines you have to draw 😄

Well, if I resample my audio to the number of pixels on a 4K screen, this means at least 3840 * 16 channels = 61440

Maybe you could first do some performace tests with random data. To see if Android is able to handle this.

OK, I think I could draw the last 16ms in a bitmap and remember the last X bitmaps (that I need to cover the screen) and then every redraw all those bitmaps in my canvas.

No you could just use one bitmap.

How so ?

You want that is moves in time?

Oh, OK double-buffering.

But performance wise it should not make a different how many bitmaps you have

OK thanks.

Maybe you can recycle the bitmaps. So reuse the bitmaps you do not need anymore

No but I will only use 2 bitmaps to do double-buffering.

Just create e.g. 10 bitmaps using remember { }

But I can't draw my canvas above itself, right ?

Just make sure that you draw on the Main thread

In an ideal world I would do:

Canvas {
  drawImage(thisCanvasUnderlyingBitmap, -pixelsFor16ms, 0)
  // now draw the new 16ms of signal
}

@Didier Villevalois have you looked at the repo I mentioned above....I still think based on what you describe that it does something quite similar

@John O'Reilly I did look but did not find the corresponding code

for example the Canvas rendering for Android app is in https://github.com/joreilly/chip-8/blob/main/androidApp/src/main/java/dev/johnoreilly/chip_8_kmm/androidApp/MainActivity.kt

Yeah OK I have seen that code. But it re-renders everything every time.

you mentioned above "In an ideal world I would do:"

Canvas {
  drawImage(thisCanvasUnderlyingBitmap, -pixelsFor16ms, 0)
  // now draw the new 16ms of signal
}

would that not also re-render every 16ms?

Yes but it do not draw the lines. So it depends on how many lines you have to draw. But as i mentioned above. Just try what happens if you draw 61440 lines every frame. Maybe it works.

Sure but I would not have to redraw all the previous signal (which means traversing all the previous data and do the computations), apart for when the layout size changes.

Maybe you could also optimize the code to reduce the number of lines a little bit

You mean store the results of the computations of the lines I have to draw ?

Just store the points for the lines an an array

Yeah...

Skia uses opengl to draw lines. It is very efficient.

Yeah, but my problem is doing the extra-work of storing my computations.

Just make sure that you do not create too many new objects every frame

In other frameworks, when you redraw, you still have what has been drawn before, you can clip part of it and move it and then draw what you need more.

Yes if you really want to do this. Than you have to do the bitmap approach.

I think I will try that approach. This is way less code for me :)

Android uses double or triple buffering, we do have the previous frames available but it is not necessarily efficient to do an old school blit copy like you mention

@romainguy No, I did not try yet. I am still assessing feasability and designing.

They are not in a format that's usable for an app

I did a small poc for this:

const val historySize = 500

fun fract(x: Float): Float = x - floor(x)
fun noise(c: Long): Float = fract(sin(c.toFloat()*100f) * 5647f)

class SignalMemory {
    private val data = Array(historySize) { 0f }
    private var pointer = 0
    val ts = mutableStateOf(0L)

    fun addData(value: Float) {
        data[pointer] = value
        pointer = (pointer+1) % data.size
        ts.value += 1
    }
    fun size() = data.size
    fun get(i: Int): Float = data[(pointer + i) % data.size]

    private var running = false
    fun start() {
        GlobalScope.launch {
            running = true
            while (running) {
                addData(noise(ts.value))
                delay(33)
            }
        }
    }
    fun stop() {
        running = false
    }
}

@Composable
fun lineTest() {
    val mem = remember { SignalMemory() }
    onActive {
        mem.start()
        onDispose {
            mem.stop()
        }
    }
    Canvas(Modifier.fillMaxSize()) {
        val size = drawContext.size
        val stepSize = size.width / mem.size().toFloat()
        val ts = mem.ts
        val currentData = ts.value // just to track data changes
        drawIntoCanvas {
            it.scale(stepSize, -(size.height / 2f))
            it.translate(0f, -1f)
            for (i in 0..mem.size()) {
                val x = i.toFloat()
                val v = mem.get(i)
                drawLine(Color.Red, Offset(x, -v), Offset(x, v), strokeWidth = 1f)
            }
        }
    }
}

Don't issue individual drawLine calls, instead do a drawLines() with a single array of lines.

Did not found this call. In which API is it?

It's on the native Canvas API

ok thx. I will try this

(which may require a cast to android.graphics.Canvas)

It is a little bit better:

Canvas(Modifier.fillMaxSize()) {
        val size = drawContext.size
        val stepSize = size.width / mem.size().toFloat()
        val ts = mem.ts
        val currentData = ts.value // just to track data changes
        val paint = Paint().apply {
            strokeWidth = 1f
            isAntiAlias = true
        }
        drawIntoCanvas {
            it.scale(stepSize, -(size.height / 2f))
            it.translate(0f, -1f)
            val lineArray = FloatArray(mem.size() * 4)
            for (i in 0 until mem.size()) {
                val x = i.toFloat()
                val v = mem.get(i)
                val offset = i * 4
                lineArray[offset] = x
                lineArray[offset + 1] = -v
                lineArray[offset + 2] = x
                lineArray[offset + 3] = v
            }
            it.nativeCanvas.drawLines(lineArray, paint)
        }
    }

You could also keep the array preallocated instead of allocating it every time

ok yes that helps

Is there a plan to have

drawLines

be part of the Compose UI Canvas API?

Feature request for @Nader Jawad 🙂

It exists, it's just labeled as

drawPoints

and pass in

PointMode.Lines

for the corresponding

PointMode

Why not also have a specialized

drawLines

?

@Nader Jawad TIL!

@louiscad, it does end up calling the framework's

drawLines

API behind the scenes and helps simplify the usage of the

stepBy

parameter to be more explicit of the intent which could be used either to sets of lines between pairs of points using PointMode.Lines or draw each line connected to create a polygon using PointModes.Polygon

@Nader Jawad Which is closer to my ideal Canvas API which would basically be more like what we do in 3D:

render(Renderable, Mask, Shader, RasterState)

or something like this

I see, thank you @Nader Jawad. Wouldn't it make sense to introduce an error level deprecated

drawLines

function, akin to deprecated operators in kotlinx.coroutines for people that know the RxJava APIs?

Which

drawLines

method are you referring to in this case? We don't expose a drawLines method in compose. I'm not sure it makes sense to deprecate the one in the framework either

kotlinx.coroutines isn't deprecating the RxJava operators either. What it's doing is using the deprecated symbols for its own types to hint the developers towards the one with a different naming. For Compose UI, it'd mean that there's a

drawLines

function that is deprecated at error level (instead of none currently), with a

ReplaceWith

clause that uses

drawPoints

, and a deprecation message that explains why

drawLines

from Compose UI is deprecated. I didn't meant to deprecate the one from Android, we're talking about the API of Compose UI here. Since it'd be deprecated at error level, it wouldn't need any implementation.

There isn't a drawLines method to deprecate so it would be odd to introduce it only to deprecate it immediately

I don't find it odd, I find it useful for people used to the

drawLines

function on Android or other platforms that have it.