Does Compose handle overdraw issue? How it will re...

# compose

[Sergey Y.]

Does Compose handle overdraw issue? How it will render multiple opaque overlaying layers?

[Sergey Y.]

I mean is it doing some specific optimizations regarding the issue?

[Leland Richardson [G]]

i don’t think we are doing anything special here. @Nader Jawad can confirm

[Leland Richardson [G]]

IIUC, overdraw isn’t nearly as much of an issue as it used to be

[Nader Jawad]

Compose is not doing anything specific to avoid overdraw so the same best practices apply.

[Sergey Y.]

Thanks for explaining. @Nader Jawad
Is any special tooling expected for Compose overdraw debugging? I'm not tried but I have feeling that current OS's tooling doesn't detect the issue with Compose because it is drawing on canvas.

[Nader Jawad]

The same overdraw developer debugging options should apply. From the OS perspective, compose is basically a View with several Drawables.

[Nader Jawad]

Also while making sure to minimize overdraw is important, mobile display resolutions have capped out at around 2k while mobile GPUs have improved their performance so overdraw today is not as much as a performance bottleneck as it was 5+ years ago

[Sergey Y.]

One thing I noticed, Show Layout Bounds is not showing any Compose bounds.

[Nader Jawad]

Interesting, do you have some sample code where it is not rendered? I know some folks on the team actually added support for compose to show the layout bounds when this setting is enabled. I just launched the compose demo app and the material rally demo does show layout bounds for me. This is done at the composable layout level but not done around each drawing call from a DrawScope implementation for example

[Andrey Kulikov]

you just need to recreate an activity (or restart the whole app) to start see it, we don't detect this setting changes on the fly currently in compose implementation

[Vinay Gaba]

compose is basically a View with several Drawables.

Interesting. Could you elaborate a bit more about what this means? Let’s assume I have a composable function with a Text composable inside it. What would this example translate to based on the statement I highlighted above.

[Vinay Gaba]

I’m guessing you didn’t mean this in an absolute sense and were just talking about it from what the overdraw logic sees it as.

[Nader Jawad]

Compose is basically a custom view, and each individual composable is getting placed/drawn from the layout paradigm it defines

[Nader Jawad]

It's still using the same canvas drawing into the same buffer provided by the activity that is given to a regular Android View

[Sergey Y.]

@Nader Jawad As @Andrey Kulikov mentioned the bounds start showing when I restarted the activity

[Nader Jawad]

We are not allocating/rendering content into a separate SurfaceView/TextureView and embedding that with the rest of the view hierarchy which is why interop with the existing framework Views "just works". AndroidComposeView is a ViewGroup and we still follow the same contract for it.

[Nader Jawad]

The overdraw logic looks at the number of times each pixel is drawn and is independent of the View hierarchy. If you have a custom View that fills it's bounds 3 times, you will see this be reflected in the overdraw debugging tool. Because compose is basically a custom view, nothing about this behavior changes as well

[Nader Jawad]

So to go back your example @Vinay Gaba, a Text composable could be thought of as TextDrawable that with it's bounds/placement defined by other layout rules defined by AndroidComposeView and other composable layouts. This is a large oversimplification as text rendering is quite complicated and is a lot more than just canvas.drawText

[Sergey Y.]

Speaking about Text. Does Compose render text on its own or it uses the system's APIs(Canvas#drawText, StaticLayout, etc) like it is doing for rendering a shadow?

[Nader Jawad]

The Text composable uses Static layout behind the scenes

[Nader Jawad]

We don't actually explicitly expose a drawText call on DrawScope (Compose's Canvas wrapper). We're working with the text team to see if we can align these usages a bit more but we find that drawText is often too simple to be useful a lot of the time and since rendering text with compose is easier and more feature rich, it's possible to mix and match custom drawing with text rendered in separate composables

[Sergey Y.]

Will be available an API similar to PreComputedText to be able to pre-render text chunks on a background thread.

[Nader Jawad]

That's a good question. Maybe @Siyamed or @Seigo Nonaka can speak to that a bit more

[Seigo Nonaka]

That is technically possible, but not yet implemented in JC. Please submit a feature request for that 🙂 .

[Leland Richardson [G]]

We should run precompute text during composition if we aren’t already

[Sergey Y.]

PrecomputedText can come in handy when it needs to display long text, broken into many small paragraphs.

[Chris Craik]

As Leland mentioned above, overdraw isn't a huge problem anymore, and we updated our overdraw page fairly recently with a note at the top: https://developer.android.com/topic/performance/rendering/overdraw