Sergey Y.

    Sergey Y.

    2 years ago
    Does Compose handle overdraw issue? How it will render multiple opaque overlaying layers?
    I mean is it doing some specific optimizations regarding the issue?
    l

    Leland Richardson [G]

    2 years ago
    i don’t think we are doing anything special here. @Nader Jawad can confirm
    IIUC, overdraw isn’t nearly as much of an issue as it used to be
    Nader Jawad

    Nader Jawad

    2 years ago
    Compose is not doing anything specific to avoid overdraw so the same best practices apply.
    Sergey Y.

    Sergey Y.

    2 years ago
    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

    Nader Jawad

    2 years ago
    The same overdraw developer debugging options should apply. From the OS perspective, compose is basically a View with several Drawables.
    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.

    Sergey Y.

    2 years ago
    One thing I noticed,
    Show Layout Bounds
    is not showing any Compose bounds.
    Nader Jawad

    Nader Jawad

    2 years ago
    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

    Andrey Kulikov

    2 years ago
    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
    v

    Vinay Gaba

    2 years ago
    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.
    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

    Nader Jawad

    2 years ago
    Compose is basically a custom view, and each individual composable is getting placed/drawn from the layout paradigm it defines
    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.

    Sergey Y.

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

    Nader Jawad

    2 years ago
    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.
    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
    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.

    Sergey Y.

    2 years ago
    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

    Nader Jawad

    2 years ago
    The Text composable uses Static layout behind the scenes
    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.

    Sergey Y.

    2 years ago
    Will be available an API similar to
    PreComputedText
    to be able to pre-render text chunks on a background thread.
    Nader Jawad

    Nader Jawad

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

    Seigo Nonaka

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

    Leland Richardson [G]

    2 years ago
    We should run precompute text during composition if we aren’t already
    Sergey Y.

    Sergey Y.

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

    Chris Craik

    2 years ago
    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