In JewelExample, I have two sliders that resize a button width and height. The resize of the button makes the parent group container resize to respect the button inner width and padding. As well the next column (that has more containers with sub controls, moves to the right or left depending on the width resize of the button. The performance seems to be good, but as it's a simple example, I can say anymore, and maybe making the same with more objects and complexity would give us some more info about how it performs.(Note that right now that example is broken since I'm refactoring the jewel slider to input range, so now it's broken hopefully for little time).
So, my question here: I suppose this is all done by how browser manages layout, or there's some Royale magic here? I assume is the first, or I'm wrong? If is the first, I think we don't need to do anymore...that's what I expect, and nothing more, if not we need to focus on what to do to make it as light wave as possible 2018-03-26 22:28 GMT+02:00 Harbs <[email protected]>: > > > On Mar 26, 2018, at 8:18 PM, Alex Harui <[email protected]> > wrote: > > > > So given all that, I think the independent issues are: > > 1) can we optimize our layouts to use browser layouts more? > > Possibly, and we should when we can. > > 2) can we optimize our layouts to avoid direct interactions with the dom? > > Possibly to a certain extent. I do think that we want to offer the best > possible performance if users can set hard values for x, y, width and > height. With hard-coded values DOM interaction could be kept to a minimum. > It would be an interesting experiment to see what would happen if we > *don’t* rely on browser layout and hard code everything. > > > 3) is there any advantage to deferring layout via requestanimationframe? > > Definitely — at least if there’s a need to read measurements. Many layouts > do need that info at some point. If measuring is standard, it’s also a good > way to make sure all the children are measured for calculating that before > layout. There needs to be a way of separating reads from writes. Although I > now believe that requestAnimationFrame is not the best way to delay > execution. There are higher resolution ways of running async code. > > Harbs -- Carlos Rovira http://about.me/carlosrovira
