I believe that everything was off by a factor of 2. What would be awesome is if regardless of screen resolution or DPI, I could always assume that the scaling magic was related to a width of 768, which I could create as a constant and problem solved. That is what I did for the renderer and it worked like a charm, but I don't know if that will work for android or all iPads??
I have a bigger issue now. The TypeErrors are gone, and all of the measuring seems to have been massively reduced, but the performance is not much better, only slightly. When tethered to Scout, the iPad button click still takes about 5000ms to slide the list onto the screen. Untethered, I would estimate it to be about 3000ms. So now the question comes down to two parts: 1) Would an actionscript itemrenderer make a noticeable difference? I am a little daunted to try it because I never have, and you already know that I have 30 labels and radiobutton and I know there will be a lot of overrides. But if you believe it will make a significant improvement, I could give it a try. 2) When the list moves up and completely covers the content behind it, how much does the content that it covers affect performance? I always assumed that it all stayed in the display list and was simply covered up temporarily. But on the main screen, I have 20 dropdownbuttons, buttons, and textinputs in heavily nested groups as well as 3 lists with itemrenderers, only one of which is visible at a time. If that all has to be removed and redrawn when the list transitions in and out, then maybe I need to trim the fat out of that code as well??? Any thoughts are appreciated. The desktop version works great, but right now, the mobile version just does not feel like a professional app :( -- View this message in context: http://apache-flex-users.2333346.n4.nabble.com/Scout-What-does-this-mean-tp14126p14156.html Sent from the Apache Flex Users mailing list archive at Nabble.com.
