>Well, if you think nobody will ever need StageTextInputSkin, then your version >should simply replace it. If you think there may be performance or memory >trade-offs where someone >will want the old one because they aren't scrolling >their StageText's then we should keep them.
I made some memory profiling (see other thread), that showed even a screen full of TI would take a few MB of memory, which seems "reasonable", at least on recent devices. Moreover, Bitmap caches is a common technique on Flex mobile (list item renderers use it intensively), and it does not seem to be an issue. One "obvious" case that could justify the use of "StyleableStageText" is the one where you have a single full-screen TextArea (12MB of bitmap proxy on retina iPad). However, using StyleableStageText in this case would still require the 12MB, but only when a popup is opened in front (which is hardly avoidable, on a normal app). So the main difference would be: - ScrollableStageText (new skin) allocates the bitmap at startup, and keep it until the TA is removed from the stage - StyleableStageText (old skin) allocates the same bitmap, every time something shows in front of the TA, and disposes it when the popup disappears. So does the old StyleableStageText really have less memory requirement even in that case? Not so sure... ----- That being said, we still need to keep the class, at least because it may have been overridden by folks (Om says so) , and I am not against keeping a few mustella tests like you suggested, to make sure it does not break in a future version of AIR. Will you help me select the ones that we need to keep? >There may be some other things you can do to the TextField-based skins (masks, >blends, >filters) that we might want to keep that around as well. Agree for the use case. But it seems like the TextField-based skin does not behave correctly on mobile (soft keyboard/autoCorrect not working, etc.) In this case, I would take another approach: With the new ScrollableStageText, you can use any DisplayObject as the proxy, not only a bitmap (see other thread). so we could derive a new class that would use TextField as the proxy (and pass it all the font styles). So of course, the filters won't be applied during editing, but that's a common usage. WDYT ? Maurice -----Message d'origine----- De : Alex Harui [mailto:aha...@adobe.com] Envoyé : lundi 18 novembre 2013 18:49 À : dev@flex.apache.org Objet : Re: [dev] Build failed in Jenkins: flex-sdk_mustella-mobile #369 On 11/18/13 9:38 AM, "Maurice Amsellem" <maurice.amsel...@systar.com> wrote: > >Anyway, I checked the xml DL, and the coordinates/extents are exactly >the same, expect that the new skin has a bitmap, so there is no >computation error and nothing we can really do about that, apart from >updating the baselines. OK, then it is probably ok to update the baselines. > >On a side note, I don't like the idea of providing 3 skins for >achieving the same result [ Editing Text in a mobile device], not >because there are >3 uses cases, but because of technical limitations of each. >I would really prefer to have ONE skin, improve/fix it until it behaves >well in all situations, and put the other ones in the "deprecated" status. > >WDYT? Well, if you think nobody will ever need StageTextInputSkin, then your version should simply replace it. If you think there may be performance or memory trade-offs where someone will want the old one because they aren't scrolling their StageText's then we should keep them. There may be some other things you can do to the TextField-based skins (masks, blends, filters) that we might want to keep that around as well. -Alex
