Will this bring any performance improvement to ren...

# compose

[Mihai Hrincescu]

Will this bring any performance improvement to rendering, measuring and layout phases or will just skip the xml parsing or the performance improvements are likely to come when the UI composing will be truly multi-threaded.

[gildor]

There is no XML parsing in existing Android Layouts on runtime, because XML is parsed on compile time

[Adam Powell]

Yes, we're reworking measure and layout for performance in compose

[Adam Powell]

The view measure and layout contact left a lot of opportunities on the table

[Mihai Hrincescu]

When i said parsing i meant the inflation process, i misspoke. If i understand correctly the new components used for drawing will basically just wrap a kind of render node used to just generate the render list, which should give big performance improvements for custom "widgets". And how would drawables integrate into this picture.

[Adam Powell]

Drawing has the same basic shape as it does for views today, views already behave the way you describe. Each view has a render node that it records drawing commands into when its draw method is called, the canvas provided there isn't directly drawing pixels in the usual code path

[Adam Powell]

drawables have some unfortunate api and legacy behavior requirements like views do, but like views people tend to have them already for other parts of their apps, so there'll be a compatibility story there

[Mihai Hrincescu]

I understand but renderNode was introduced in api level 29 so before there was no way that i know of to break a complex view into smaller parts so you could rerecord just part of the display list of a view. So this looks very promising. Thanks for the clarification.

[gildor]

When i said parsing i meant the inflation process, i misspoke

I believe that biggest problem of current view inflation is not inflation process and even reflections, but biggest part is just constructor invocation, because it’s pretty heavy on every view, and Compose I hope will solve this problem

[Adam Powell]

Bingo. View constructors do tons of work and several calls to Context.obtainStyledAttributes, one for each layer of inheritance. That's gotten more expensive as themes have also become more complex and layered.

[gildor]

@miha-x64 Why 🚫 ? Could you show me layout xml on runtime?

[miha-x64]

It's not a straight XML, but it still must be parsed.