I assume this was a release version and not a debug version? Either way, I don't think TLF will get out to 25fps. I'd suggest doing a simple test to see if TextField really can do RTL (text starting from the right edge) or just knows how to place characters in a string based on some positioning information.
-Alex On 3/24/14 1:46 PM, "Maurice Amsellem" <maurice.amsel...@systar.com> wrote: >I just did a quick test to compare TLF and TextField on mobile. >Basically, replaced StyleableTextField cell renderer on MobileGrid by >spark Label-based renderer. > >Test results: >- iPad 3 (retina) >- "slow" iOS packaging , GPU rendering >- Mobile grid with 4 columns of text, and 200 rows > >StyleableTextField => 25 fps when scrolling >Spark Label => 1 to 3 fps when scrolling ( UI is very slow, almost >frozen). > >So of course mobile grid displays a lot of text, including multi-line, >but that's where performance is needed, not on button and titles, IMO. >I could also have used TextLine, but it does not support multi-line, >which TextField does, so it's not equivalent. > >So for me, spark Label is not good enough on mobile, even on recent >devices. >I will explore the other track (RTL using TextField). > >What do you think? > >Maurice > >-----Message d'origine----- >De : Maurice Amsellem [mailto:maurice.amsel...@systar.com] >Envoyé : lundi 24 mars 2014 11:19 >À : dev@flex.apache.org >Objet : RE: RTL support in mobile apps > >Hi Carlos, > >1) It's not proven yet that TLF is "fast enough" on mobile, especially >when there are lots of text to display, such as in lists of datagrid. >Plus I have discovered that the "old" TextField is actually capable to >display RTL , but the Flex positioning is broken, so the text does not >appear (probably because it was not supposed to work that way). >So IMO, the question is still open, and I won't rush into replacing >TextField by TLF on mobile. >It would be probably much simpler to fix the layout. > >>Right now we need to deal in different ways with TextInput in mobile and >>browser and this defeat the "code once run everywhere". >What do you mean? From the SDK developer standpoint, or from the >end-user developer stand point ? >From the SDK standpoint, the difference is only on the skin, the 'host' >component is the same. >From the end-user developer, you must use TextInput in both cases, so >where's the difference ? >The behavior is different, but that's inherent to mobile vs desktop (eg. >you don't have softkeyboard or restricted keyboards on desktop). > >Please explain > >Maurice >-----Message d'origine----- >De : carlos.rov...@gmail.com [mailto:carlos.rov...@gmail.com] De la part >de Carlos Rovira Envoyé : lundi 24 mars 2014 10:54 À : >dev@flex.apache.org Objet : Re: RTL support in mobile apps > >Hi, > >if there are plans to introduce TLF on mobile TextInput this will change >my priorities about change the internals of MaskedTextInput component and >will only make it to preserve slot positions. > >IMO, if now TLF give us a good performance in mobile this days it will be >very useful to make it happen since this will be more aligned to the Flex >philosophy. Right now we need to deal in different ways with TextInput in >mobile and browser and this defeat the "code once run everywhere". > >So +1 to TLF support on mobile is performance is good! :) > >Please let me know if that's are the plans. > >Thanks! > >Carlos > > > > >2014-03-23 21:08 GMT+01:00 Maurice Amsellem <maurice.amsel...@systar.com>: > >> Found a number of tickets on this topic: >> >> https://issues.apache.org/jira/browse/FLEX-26365 (closed as "later") >> https://issues.apache.org/jira/browse/FLEX-34145 (closed) >> https://issues.apache.org/jira/browse/FLEX-34181 (In progress) >> https://issues.apache.org/jira/browse/FLEX-33750 (open) >> https://issues.apache.org/jira/browse/FLEX-28107 (later) >> https://issues.apache.org/jira/browse/FLEX-28103 (later) >> https://issues.apache.org/jira/browse/FLEX-26169 (later) >> https://issues.apache.org/jira/browse/FLEX-24502 (later) >> >> Maurice >> >> >> -----Message d'origine----- >> De : Maurice Amsellem [mailto:maurice.amsel...@systar.com] >> Envoyé : samedi 22 mars 2014 01:14 >> À : dev@flex.apache.org >> Objet : RE: RTL support in mobile apps >> >> Yes, that might me the answer: so I need to "cancel" the flipping like >> I did for StageText (and like is done in spark Label). >> I will try this tomorrow. >> >> Still does not explain why TextField accepts bidi text now ? >> >> Maurice >> >> -----Message d'origine----- >> De : Alex Harui [mailto:aha...@adobe.com] Envoyé : samedi 22 mars 2014 >> 01:09 À : dev@flex.apache.org Objet : Re: RTL support in mobile apps >> >> Again, I was not highly involved in this code, but IIRC, the TextLines >> are never flipped, so if you choose a flipped layoutDirection the >> TextLines are re-flipped. But if you start flipping TextFields >> without embedded text they go blank. >> >> Does that explain what you're seeing? >> >> -Alex >> >> On 3/21/14 5:00 PM, "Maurice Amsellem" <maurice.amsel...@systar.com> >> wrote: >> >> >Thanks Alex. That was also my understanding. >> > >> >Regarding TextInput / TextArea, there is no issue with regard to RTL >> >in using StageText ( embedded in StyleableStageText or >>ScrollableStageText) . >> > >> >Now something strange that gets me puzzled. >> > >> >I did some experiments with mobile components that use TextField >> >(actually StyleableTextField) and I managed to displayed >> >Arabic/Hebrew (list , titles and nav bar) >> > >> >https://www.dropbox.com/s/4e4untcp3f4jeb2/List_arabic_LTR.png >> > >> >But this works only if the surrounding View or the application >> >layoutDirection is set to "ltr". >> >And indeed, you notice that the text is RTL but the layout is still >>LTR. >> > >> >Now, if I set layoutDirection to RTL either at the Application or >> >View , then everything disappears: >> > >> >https://www.dropbox.com/s/jzu1veecjm64m51/list_Arabic_RTL.png >> > >> > >> >I thought that layoutDirection = RTL was "merely" applying a >> >mirroring transform to the display. >> > >> >I am confused. >> > >> >Maurice >> > >> >-----Message d'origine----- >> >De : Alex Harui [mailto:aha...@adobe.com] Envoyé : samedi 22 mars >> >2014 >> >00:44 À : dev@flex.apache.org Objet : Re: RTL support in mobile apps >> > >> >I wasn't on the mobile components team (I did some mobile work but >> >mostly worked on other SDK stuff), but fundamentally, if there's a >> >TextField involved, then there is no RTL support. You need TextLines >> >for RTL. You may be able to swap in the "desktop" skins for >> >TextInput/TextArea and pay the performance and memory hit to get RTL >> >text, but then I'm not sure how well StageText will work with that, >> >if at all. Essentially, the mobile team traded off RTL support for >> >better performance. Now, that was several years ago and phones and >> >tablets are faster, so it might be worth revisiting that decision. >> > >> >-Alex >> > >> >On 3/21/14 3:41 PM, "Maurice Amsellem" <maurice.amsel...@systar.com> >> >wrote: >> > >> >>Hi Team, >> >> >> >>Ori Segal has reported a problem in TextInput default skin with RTL >> >>(Hebrew, arabic) layout. >> >>I have fixed this problem. >> >> >> >>Now he has reported a problem in TextInput "prompt" text not being >> >>displayed in RTL. >> >> >> >>So I did a small test: set layoutDirection="rtl" to a sample mobile >> >>app (with buttons, mobilegrid, etc..) and almost every text >>disappeared. >> >> >> >>The only texts that seem to be displayed correctly are: >> >>- TextInput / TextArea with the default text (that is using native >> >>StageText) >> >>- spark Label, that is using TextLine (and the new FTE/TLF engine). >> >>Everything else, that uses the mobile-optimized StyleableTextField, >> >>will not display RTL (apparently because it's based on the old >> >>TextField engine). >> >> >> >>Reading the articles below, it seems clear enough that RTL is NOT >> >>supported on AIR mobile (with a few exceptions): >> >> >> >>http://sourceforge.net/adobe/flexsdk/wiki/Mobile%20Text%20Components >> >>/ >> >>http://help.adobe.com/en_US/flex/using/WS02f7d8d4857b1677-165a04e112 >> >>69 >> >>5 >> >>1a2 >> >>d98-7ffe.html >> >>http://help.adobe.com/en_US/flex/using/WS02f7d8d4857b1677-165a04e112 >> >>69 >> >>5 >> >>1a2 >> >>d98-7ffd.html >> >> >> >>Alex, as you seem to have been involved in that, do you confirm? >> >> >> >>Something else: >> >>The first article says: >> >>" Primarily for performance reasons and support for native >> >>predictive text input and editing, mobile will use TextField-based >> >>text in all critical areas. This is expected to be a short-term >> >>solution until a performant version of FTE arrives on mobile." >> >> >> >>So has FTE been optimized for mobile since the article was written , >> >>for example in AIR 4.0? >> >> >> >> >> >>Thanks >> >> >> >>Maurice >> > >> >> > > >-- >Carlos Rovira >Director de Tecnología >M: +34 607 22 60 05 >F: +34 912 94 80 80 >http://www.codeoscopic.com >http://www.directwriter.es >http://www.avant2.es
