Well, if you can see a gradient behind the text and you are getting 20 fps, and that is comparable to native apps, then I guess that these devices have gotten faster. IIRC, there was a lot of concern in the early days when devices were much slower, and concern again when retina screens required more pixels to be drawn, but maybe now it is less of a problem.
Thanks for being thorough. -Alex On 2/24/14 4:25 PM, "Maurice Amsellem" <maurice.amsel...@systar.com> wrote: >This is what I did to test performance of useOpaqueBackground=false >against a "complex" background : > >- turned off alternatingItemColors (so that items have transparent text) >- set itemRenderer opaqueBackground to false >- set the List contentBackgroundAlpha to 0 >- draw a splendid LinearGradient behind the list >-The list is full screen, and displays several text items, >- 200 rows. > >Tested on iPad3 retina, renderMode=gpu, iOS packaging = slow. > >=> 20 ~24 FPS when scrolling, so perfect ( transparent text scrolling >over a gradient background) > >AIR Mobile does very well indeed, or maybe it's the iPad 3 ;-). > >-----Message d'origine----- >De : Maurice Amsellem [mailto:maurice.amsel...@systar.com] >Envoyé : mardi 25 février 2014 00:36 >À : Alex Harui; dev@flex.apache.org >Objet : RE: Need your help on problem with opaqueBackground > >>My understanding is that opaque background speeds up bitmap renderings >>because it doesn't have to consider anything behind. > >Yes, that's correct. >In my tests, the background is only the app and view background, so >probably some solid color rectangles. >So maybe If I put some components, or some bitmap in the background, that >would slow down more when opaqueBackground is set to false. >Any other test idea ? >I will do the tests. > >Maurice > >-----Message d'origine----- >De : Alex Harui [mailto:aha...@adobe.com] Envoyé : lundi 24 février 2014 >23:56 À : dev@flex.apache.org; Maurice Amsellem Objet : RE: Need your >help on problem with opaqueBackground > >My understanding is that opaque background speeds up bitmap renderings >because it doesn't have to consider anything behind. > > > > >Sent via the PANTECH Discover, an AT&T 4G LTE smartphone. > >Maurice Amsellem <maurice.amsel...@systar.com> wrote: > > >Although it's not clearly stated in the documentation, my understanding >of "opaqueBackground", is that , when used with cacheAsBitmap, it will >create an opaque bitmap for the renderer, And and opaqueBackground is not >set, it will create a transparent bitmap (with a mask). > >I made some performance testing enabling / disabling opaqueBackground to >see how it would degrade the performance. > >(renderMode= gpu , iPad3 retina, "slow" iOS packaging, scrolling >through a 200 items list, and displaying the FPS). > >No noticeable difference between the two modes (opaqueBackground / not >opaqueBackground). > >That's surprizing me. Maybe gpus are fast enough today to process equaly >well transparent and opaque bitmaps. > >Anyway, that makes everything much simpler now: >I will throw away all my code (2 days wasted :-( ) , and just replace it >with a manual option in spark:List to use or not opaqueBackground for >renderers. > >Anyway, thanks a lot for the great idea. > >Maurice > >-----Message d'origine----- >De : Alex Harui [mailto:aha...@adobe.com] Envoyé : lundi 24 février 2014 >18:17 À : dev@flex.apache.org Objet : RE: Need your help on problem with >opaqueBackground > >Well, this is the kind of torture that happens when code attempts to fool >the player. > >If there is a way to configure the renderer such that no text is clipped >and no textfields extend beyond the desired boundaries of the renderer, >then you can set opaque background. But if the configuration is such >that you can't, you might have to trade-off performance for accuracy by >not setting opaque background. I'd probably add some flag that controls >whether you run new code paths or leave it as it was. > >-Alex >________________________________________ >From: Maurice Amsellem [maurice.amsel...@systar.com] >Sent: Monday, February 24, 2014 8:51 AM >To: dev@flex.apache.org >Subject: RE: Need your help on problem with opaqueBackground > >>So, you may need to override opaque background and draw it yourself. > >Actually the colored background is drawn twice: >1) in drawBackground, using drawRect, for mouse hit testing >(opaqueBackground does not react to mouse hit, apparently). >2) using opaqueBackground, so that bitmap caching and scrolling are >faster: this is done by AIR, and cannot be overridden IMO drawBackground >& opaqueBackground are only set is there is a backgroundColor. > >So I don't think I can remove the opaqueBackgorund, or emulate it. > >---- > >FYI, I am almost done with the fix, following the proposal below: >- extent the top padding when font is large and tightTopOffset > >topPadding, to account for opaqueBackground. >- modify tightTextTopOffset to include descent ( I have made this one an >mx_internal option to STF, turned off by default, could be removed if >necessary ). > >It seems to be working fine. I will run the Mobile mustella tests to >make sure there are no regressions. > >Maurice > >-----Message d'origine----- >De : Alex Harui [mailto:aha...@adobe.com] Envoyé : lundi 24 février 2014 >15:57 À : dev@flex.apache.org; Maurice Amsellem Objet : RE: Need your >help on problem with opaqueBackground > >Imo once the code starts doing magic the code must do more magic to >emulate other player behavior. So, you may need to override opaque >background and draw it yourself. > > > > >Sent via the PANTECH Discover, an AT&T 4G LTE smartphone. > >Maurice Amsellem <maurice.amsel...@systar.com> wrote: > > >Alex, please ignore (most of ) previous email. > I was on the wrong path, thinking the issue was in the sizing, while it >was in the positioning: > >To do that, I has set the opaqueBackground and the item background to >different colors: >https://issues.apache.org/jira/secure/attachment/12630646/IconItemRenderer >%20with%20debug%20colors.jpg > >-The light colors (light green, ligh red) represent the Flex-drawn >backgrounds >- the saturated colors is from the opaqueBackground. > >What it shows is that: > -> when top padding is lower than tight tightTopOffset, then overflow >will occur, because opaque background is also Drawn in the empty pixels >above the text. >In the attached screenshot, second item top offset leaks over first item >(leak is the saturated green rectangle). > >Since padding is fixed (depends only on the DPI) but tightTopOffset >depends on the text size, Over a given font size, overflow will occur: > >For IconItemRenderer, top padding is set to 6 pixels, and tightTopOffset >for a 50pix font is 12. >Probme does not show for LabelItemRenderer, because top padding is set to >12 pixels. > > >Solution: >When the top padding is < tightTopOffset, use tightTopOffset as the top >padding for text, so that overflow does not occur. > >What do you think ? > >Maurice > >[truncated]
