On 11/16/16, 11:19 PM, "bilbosax" <[email protected]> wrote:
>I can tell from using Scout that a large chunk of time is used doing >measuring, which I assumed was because of the calculation of sizing >everything. I chose to use groups because I found out very quickly that on >mobile, pixel densities and screen resolutions vary a lot among the large >number of devices. This causes problems because if you use an absolute >number for X or y, it may get scaled based on the pixel density of your >device leading to unexpected results. Going with percentage-based Groups >insured that everything would look right regardless of the device. I guess >the cost is performance. Tomorrow, I will try to lay everything out using >absolute positioning. I just don't know if it will turn out significantly >faster because I will still have to manually calculate the distance of all >of these elements. Again, before setting explicit widths, first try running a custom layout pass so you don't need all of those groups. Some code could simply do: Var w:Number = renderer.width; SomeLabel.width = .15 * w; SomeLabel2.width = .06 * w; ... Var colWidth:Number = w * .15; SomeLabel.x = colWidth; ... This should get rid of the Groups and result in fewer measure calls on the components. > >So I can work on the performance issues of the renderer, but what about >these hundreds of TypeErrors? Do you see anything in my code that could be >triggering those? Getting rid of the binding should get rid of the TypeErrors. Binding uses an anonymous function in some cases to listen and respond for changes. Some of the bindings were to group1.width. Your new custom layout will compute group1.width and set it on the right components. HTH, -Alex
