What would be the best way to accomplish the following layout with compose? (only the two-direction ...

# compose

[Guilherme Almeida]

What would be the best way to accomplish the following layout with compose? (only the two-direction scrolling part, the sticky microphones column on the side belongs to a different layout)
I tried the naive implementation of having a LazyColumn with LazyRows inside but syncing the rows to have the same scroll position gave me bad results performance wise and I am sure it is not the best way to go about it.
Is there a “straightforward” way to get there or is building a custom LazyLayout the only way to go here?

untitled.webm

[mgrazianodecastro]

How about:

Lazy column { LazyRow { Box { Column { Row { Track } } } } }

if this offers limitation, than I would go with the layout approach

[Guilherme Almeida]

If I understood correctly LazyColumn would have a single LazyRow inside and then LazyRow would have a single Box inside, right?
I think this way I would not leverage the laziness from LazyColumn and LazyRow as they would have to measure the entire Box at once right?
Looks like it would be as having a Box with verticalScroll and horizontalScroll modifiers 🤔

[Andrew Neal]

https://danielrampelt.com/blog/jetpack-compose-custom-schedule-layout-part-2/ You'd probably find this article useful. It takes you through creating a "schedule layout", which is fairly similar to what you're going for.

[Guilherme Almeida]

Thank you! A custom layout seems to be the way to go about it, I just need to understand how lazy layouts work now 🙌

[mgrazianodecastro]

yeah, it's a real challenge. Tell us in the future how did you tacle it, curious to see it

[gildor]

Oh wow, it’s a strange feeling when someone asks how to implement layout on development of which you participated
Everything there is custom rendering (excluding bottom panel and toolbar), not yet on compose, but if we will reimplement the whole screen one day, I believe we will keep the same structure,, tracks view (view with all tracks an regions) will be still custom rendering, just using compose canvas instead of view canvas

[gildor]

You cannot get good performance for similar view without custom rendering, believe me, we tried

[gildor]

@Guilherme Almeida The easiest way to see how it works: send me your CV, and after a couple interviews the sources are yours 😉

[Guilherme Almeida]

Ah nice! Can't get better insight than this 🙌
Thank you so much and great work on the app, definitely a huge reference for me at the moment 😁
Yesterday I started looking into the LazyLayout composable and I think in conjunction with the custom views for the triggers I should be able to achieve what you proposed, thanks again!

I've actually considered the open Android position, but I live way too far from Singapore 😅

[Guilherme Almeida]

Ah, reading through it again I just realized you did not implement custom a layout for it, you straight up draw it in Canvas! I’m slow at times 🤦

[gildor]

We do offer remote positions too, we have people from Europe to Singapore 😜

[gildor]

Yes, the layout is not enough, because the problem is large elements out of point of View

[mgrazianodecastro]

when you mean a custom view, you mean drawing and handling clicks in a canvas view?

[gildor]

Correct, drawing and touch handling

[Guilherme Almeida]

@gildor Sorry for coming back to this, do you have any substancial perfomance tip? I am currently drawing everything on canvas and the performance is OK (looking at the GPU profiler I still get some frame drops occasionally), but I am drawing way less components then I can see on BandLab and getting way worse performance 😅

[gildor]

I would recommend first check that your do not have recomposition caused by your drawing
Then check not GPU profiler, but allocation tracker and make sure that you do not allocate/do heavy computations onDraw