Interesting to further note: The first time the content is fit, the parent object gets its size hard-coded. That knocks subsequent down to about a third of the time.
> On Mar 27, 2018, at 1:22 AM, Harbs <[email protected]> wrote: > > Case in point: > > In my app, I’m using OneFlexibleChildHorizontalLayout which uses flexbox. > Great. No need for writing values. Right? > > Not so fast. > > I have fit to view functionality in my app which needs to get the size of the > flexibleChild which is the container to figure out how much to scale the > content. The entire fit function takes 36 ms to run. The height getter on the > flexibleChild *alone* takes 14 ms. If the size of the flexibleChild was > hard-coded, the getter would not take measurable time. > > I have tons of hard coded size and positioning of SVG in my app (literally > hundreds of DOM objects) and it runs ridiculously fast compared to all the > Recalculate Styles which are caused by default browser layout. > > I’d really love to get some hard numbers from comparing the approaches. > > Harbs > >> On Mar 26, 2018, at 11:28 PM, Harbs <[email protected] >> <mailto:[email protected]>> wrote: >> >> 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. >
