https://kotlinlang.org logo
#compose
Title
# compose
m

Mihai Hrincescu

06/09/2019, 12:46 PM
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.
g

gildor

06/09/2019, 1:07 PM
There is no XML parsing in existing Android Layouts on runtime, because XML is parsed on compile time
🚫 1
a

Adam Powell

06/09/2019, 1:43 PM
Yes, we're reworking measure and layout for performance in compose
3
👍 1
The view measure and layout contact left a lot of opportunities on the table
m

Mihai Hrincescu

06/09/2019, 2:11 PM
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.
a

Adam Powell

06/09/2019, 2:43 PM
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
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
m

Mihai Hrincescu

06/09/2019, 2:56 PM
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.
g

gildor

06/10/2019, 1:34 AM
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
a

Adam Powell

06/10/2019, 3:53 AM
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.
g

gildor

06/11/2019, 10:45 AM
@miha-x64 Why 🚫 ? Could you show me layout xml on runtime?
m

miha-x64

06/11/2019, 11:25 AM
It's not a straight XML, but it still must be parsed.