Mailing-List: contact dev-help@flex.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@flex.apache.org
Received-SPF: unknown (athena.apache.org: error in processing during lookup of
 aharui@adobe.com)
From: Alex Harui <aharui@adobe.com>
To: "dev@flex.apache.org" <dev@flex.apache.org>, Maurice Amsellem
	<maurice.amsellem@systar.com>
Subject: RE: Need your help on problem with opaqueBackground
Thread-Topic: Need your help on problem with opaqueBackground
Thread-Index: 
 Ac8wmBh71+J+I3gKThiIHyBtKl32ZgAHkNYBAALtz7AAAihBEQAAYF0wAARUXNAAEDB+mwAJM6tAAAQ7JRAABy4TIgAC23VgAAG5JMsAA4W6wAAIl89b
Date: Mon, 24 Feb 2014 22:55:31 +0000
Message-ID: <moqtw6xcilaydk22yf7r1skg.1393282524949@email.android.com>
References: 
 <2095F5EBE04D59409DFCE91FFCEBF7AFAF2A4446@EXMBX05.netplexity.local>
 <d14f5aa3452649f7bb99e711ac3a677a@BL2PR02MB500.namprd02.prod.outlook.com>,<2095F5EBE04D59409DFCE91FFCEBF7AFAF2A4507@EXMBX05.netplexity.local>
 <4f96cc6022114286824a3e737d6aafa0@BL2PR02MB500.namprd02.prod.outlook.com>
 <2095F5EBE04D59409DFCE91FFCEBF7AFAF2A4598@EXMBX05.netplexity.local>,<2095F5EBE04D59409DFCE91FFCEBF7AFAF2A4621@EXMBX05.netplexity.local>
 <8768ecf2d9054c058822f5038d9abc5f@BLUPR02MB502.namprd02.prod.outlook.com>
 <2095F5EBE04D59409DFCE91FFCEBF7AFAF2A4A9F@EXMBX05.netplexity.local>,<2095F5EBE04D59409DFCE91FFCEBF7AFAF2A4B9C@EXMBX05.netplexity.local>
 <wlh93px098euhm252qgcb4mm.1393253817606@email.android.com>,<2095F5EBE04D59409DFCE91FFCEBF7AFAF2A4D85@EXMBX05.netplexity.local>
 <0e9e46ac3a2c49a8992474c82cf0b436@BLUPR02MB502.namprd02.prod.outlook.com>,<2095F5EBE04D59409DFCE91FFCEBF7AFAF2A4EC9@EXMBX05.netplexity.local>
In-Reply-To: 
 <2095F5EBE04D59409DFCE91FFCEBF7AFAF2A4EC9@EXMBX05.netplexity.local>
Accept-Language: en-US
Content-Language: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0

My understanding is that opaque background speeds up bitmap renderings beca=
use it doesn't have to consider anything behind.


Sent via the PANTECH Discover, an AT&T 4G LTE smartphone.

Maurice Amsellem <maurice.amsellem@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 (w=
ith a mask).

I made some performance testing enabling / disabling opaqueBackground to se=
e how it would degrade the performance.

(renderMode=3D gpu ,  iPad3 retina,  "slow" iOS packaging,  scrolling throu=
gh a 200 items list, and displaying the FPS).

No noticeable difference between the two modes (opaqueBackground / not opaq=
ueBackground).

That's surprizing me. Maybe gpus are fast enough today to process equaly we=
ll 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 wi=
th a manual option in spark:List to use or not opaqueBackground for rendere=
rs.

Anyway, thanks a lot for the great idea.

Maurice

-----Message d'origine-----
De : Alex Harui [mailto:aharui@adobe.com]
Envoy=E9 : lundi 24 f=E9vrier 2014 18:17
=C0 : 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 t=
he player.

If there is a way to configure the renderer such that no text is clipped an=
d no textfields extend beyond the desired boundaries of the renderer, then =
you can set opaque background.  But if the configuration is such that you c=
an't, you might have to trade-off performance for accuracy by not setting o=
paque 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.amsellem@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 (opaqueBackgrou=
nd 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 & opaque=
Background 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 necessa=
ry ).

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:aharui@adobe.com] Envoy=E9 : lundi 24 f=E9vrier 201=
4 15:57 =C0 : dev@flex.apache.org; Maurice Amsellem Objet : RE: Need your h=
elp 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.amsellem@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 wa=
s in the positioning:

To do that, I has set the opaqueBackground and the item background to diffe=
rent 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 backgrou=
nds
- 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 t=
he text.
In the attached screenshot, second item top offset leaks over first item (l=
eak 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 fo=
r a 50pix font is 12.
Probme does not show for LabelItemRenderer, because top padding is set to 1=
2 pixels.


Solution:
When the top padding is < tightTopOffset, use tightTopOffset as the top pad=
ding for text, so that overflow does not occur.

What do you think ?

Maurice

-----Message d'origine-----
De : Maurice Amsellem [mailto:maurice.amsellem@systar.com]
Envoy=E9 : lundi 24 f=E9vrier 2014 10:57
=C0 : dev@flex.apache.org
Objet : RE: Need your help on problem with opaqueBackground

>I looked quickly at how tightTextHeight gets computed and it seems to use =
measuredTextSize.y which seems to use textHeight, which I thought included =
descent if there are any >descenders in the glyphs for the text to be displ=
ayed.

  _tightTextHeight =3D measuredTextSize.y - _tightTextTopOffset - bottomOff=
set; bottomOffset =3D StyleableTextField.TEXT_HEIGHT_PADDING/2 + metrics.de=
scent [+ metrics.leading];

So it does not include the descent   (and the debugging figures confirm tha=
t).

>I think the problem is in getTextTopOffset.  It appears to be scanning a b=
itmap for the top of the glyphs!  I thought there were lineMetrics informat=
ion that could be used to compute it.

I have found nothing in the docs that comes closes to getTextTopOffset, in =
TextLineMetrics except the 2-pix top gutter.
http://help.adobe.com/en_US/FlashPlatform/reference/actionscript/3/flash/te=
xt/TextLineMetrics.html

The actual topTextOffset values are 5 pixels for font-12, and 12 pixels for=
 font-50, so it's not minor.

>For #1, the STF is saying it only needs to be big enough to show the top a=
nd bottom of all of the glyphs, and then there is probably some other magic=
 somewhere such that, when it is >actually sized, it makes itself a little =
bigger so the player can show the gutter/padding around the text.  If the S=
TF was actually sized to tightTextHeight, the gutter/padding would clip the=
 >text.  Then getLayoutBoundsHeight() has to fix that magic so when asked, =
the STF does appear to have just enough height for the glyphs.

I agree with the principle of that, although I am not sure that the "magic"=
 computations are correct (have to check)

But even assuming the computations are correct, there is still a problem wi=
th the way it's used in mobile item renderers:

- LabelItemRenderer is using tightTextHeight of its STF children to compute=
 its height
- BUT *opaqueBackground* is using the actual size of its STF children to co=
mpute the size of the opaque background.

Since one is much larger than the other, it's overflowing on the other rend=
erers, with the side effect that selection is clipped and bottom separators=
 are hidden when using large fonts.
(for smaller fonts, the padding compensate for that).
----

IMO, the (complex) solution would be that LabelItemRenderer extents (includ=
ing padding) and opaqueBackground extents match, so that it doesn't overflo=
w.

Need to think about it more...

Maurice

-----Message d'origine-----
De : Alex Harui [mailto:aharui@adobe.com] Envoy=E9 : lundi 24 f=E9vrier 201=
4 06:20 =C0 : dev@flex.apache.org Objet : RE: Need your help on problem wit=
h opaqueBackground

Hmm.  I looked quickly at how tightTextHeight gets computed and it seems to=
 use measuredTextSize.y which seems to use textHeight, which I thought incl=
uded descent if there are any descenders in the glyphs for the text to be d=
isplayed.  So to me, the code looks ok, but I'm not debugging into it like =
you are.  For #1, the STF is saying it only needs to be big enough to show =
the top and bottom of all of the glyphs, and then there is probably some ot=
her magic somewhere such that, when it is actually sized, it makes itself a=
 little bigger so the player can show the gutter/padding around the text.  =
If the STF was actually sized to tightTextHeight, the gutter/padding would =
clip the text.  Then getLayoutBoundsHeight() has to fix that magic so when =
asked, the STF does appear to have just enough height for the glyphs.

I think the problem is in getTextTopOffset.  It appears to be scanning a bi=
tmap for the top of the glyphs!  I thought there were lineMetrics informati=
on that could be used to compute it.

-Alex

________________________________________
From: Maurice Amsellem [maurice.amsellem@systar.com]
Sent: Sunday, February 23, 2014 1:56 PM
To: dev@flex.apache.org
Subject: RE: Need your help on problem with opaqueBackground

More findings (and questions):

I am considering the case when StyleableTextField useTightTextBound=3Dtrue =
 (regular r/o labels):

1) getPreferredBoundsHeight() returns tightTextHeight (which is basically t=
he pixel height of "T" for single line text, and top pixel to baseline of l=
ast line for multineline )

The comment says " This is the height used for positioning text according t=
o its baseline"

- I think that is OK for text with no descent (such as "Table") but not if =
text that has descent (ex "Expected").
In doubt, I would take the higher measure, not the lower one, to make sure =
no clipping occurs.

2) getLayoutBoundsHeight() returns  height - (measuredTextSize.y - tightTex=
tHeight) The comment says:
   // we want to return the text field height without the top and bottom of=
fsets
   // (measuredTextSize.y - tightTextHeight) gives us the sum of top and bo=
ttom offsets

- The first comment makes sense (height without offsets).
But the calculation really does not make sense to me !?!

IMO, both functions should return the same value, that is the height from t=
he top pixel to the bottom pixel of the text, majored to make sure no clipp=
ing occurs.

It should simply be:

tightTextHeight + metrics.descent

what do you think ?

Maurice

-----Message d'origine-----
De : Maurice Amsellem [mailto:maurice.amsellem@systar.com]
Envoy=E9 : dimanche 23 f=E9vrier 2014 20:37
=C0 : dev@flex.apache.org
Objet : RE: Need your help on problem with opaqueBackground

>I agree that the logic may need fixing.  It may not have been tested at
>large font sizes

Yes.  In fact, for small enough fonts, the measuring/layout computations ap=
proximations were somehow compensated by big enough paddings.

I have seen that useTightTextBound=3Dtrue is for regural text and useTightT=
extBound=3Dfalse for editable text (TextArea, TextInput).

So I will focus on the case where useTightTextBound =3D true, to minimize t=
he impact.

This will probably break some Mustella mobile tests.

Maurice

-----Message d'origine-----
De : Alex Harui [mailto:aharui@adobe.com] Envoy=E9 : dimanche 23 f=E9vrier =
2014 20:10 =C0 : dev@flex.apache.org Objet : RE: Need your help on problem =
with opaqueBackground

I agree that the logic may need fixing.  It may not have been tested at lar=
ge font sizes.

IIRC, tight text bounds tries to ignore the "gutter" around the textfield. =
 There is always a few more pixels in the TextField around the actual text.

-Alex
________________________________________
From: Maurice Amsellem [maurice.amsellem@systar.com]
Sent: Sunday, February 23, 2014 10:25 AM
To: dev@flex.apache.org
Subject: RE: Need your help on problem with opaqueBackground

The 15% was an empirical finding based on comparing "unscaledHeight" and th=
e apparent physical height in pixels of the renderered item.
So let's forget this for a moment, as I don't know where it comes from.

Searching more, I found something else:
StylableTextField has "useTightTextBounds=3Dtrue", which is logical, as we =
want precise measurement.

In the measure() function of IconItemRenderer, the preferred height of the =
text is retrieved by calling :
STF.getPreferredBoundHeight() which returns, in this case , tightTextHeight=
 (let's say 36 in our example).

So one would think that when the STF is sized in layoutContents(), using th=
e same value, the text will get the same height:
layoutContents()
   labelDisplay. setLayoutBoundsSize ( width, 36).

But in StylableTextField. setLayoutBoundsSize(),  there is some logic regar=
ding useTightTextBounds

And at the end it set text.height =3D 63 !! (instead of 36).

I don't know if   SFT. setLayoutBoundSize (STF.getPreferredWidth() , STF.ge=
tPreferredBoundHeight)  should be a no-op,

I wonder if this logic needs to be reviewed ??

 Line 1687 and follows:

     if (useTightTextBounds)
        {
            if (newHeight > 0)
            {
                var bottomOffset:Number =3D measuredTextSize.y - tightTextT=
opOffset - tightTextHeight;

                // when clipping, allow gutter to be outside of height
                // use 2x gutter (actual gutter is not part of tight text h=
eight)
                // when newHeight=3D=3D1, actual visible height=3D=3D3 (1px=
 + 1x gutter)
                if (newHeight < tightTextHeight)
                    bottomOffset =3D StyleableTextField.TEXT_HEIGHT_PADDING=
;

                // re-add the top and bottom offsets.  (measuredTextSize.y =
- tightTextHeight) gives us
                // the sum of top and bottom offsets
                newHeight +=3D (tightTextTopOffset + bottomOffset);
            }
        }
   this.height =3D newHeight;


Maurice

-----Message d'origine-----
De : Alex Harui [mailto:aharui@adobe.com] Envoy=E9 : dimanche 23 f=E9vrier =
2014 17:45 =C0 : dev@flex.apache.org Objet : RE: Need your help on problem =
with opaqueBackground

The TextField extent is surprising to me.  What does it mean to be 15% larg=
er?  What does transform.pixelbounds show?  Does it have to do with the bor=
der or background property?

-Alex
________________________________________
From: Maurice Amsellem [maurice.amsellem@systar.com]
Sent: Sunday, February 23, 2014 5:20 AM
To: dev@flex.apache.org
Subject: Need your help on problem with opaqueBackground

Hi team,

Piotr has raised an interesting issue in mobile apps:
https://issues.apache.org/jira/browse/FLEX-34107

When using a large font (size > 40) with IconItemRenderer on spark List, th=
e bottom separators between items are not displayed.

After some hours of debugging, I finally found the cause, but don't know ho=
w to fix it, because it's related to AIR.

Here is the story, in short (details in the ticket):


-          Mobile item renderers "opaqueBackground=3Dcolor" property draws =
an opaque background behind item renderers, to make scrolling faster (no tr=
ansparency).

-          When StyleableTextField (text used in mobile renderers, inheriti=
ng from TextField) is given WxH size in flex, its actual extent will be aro=
und 15% larger

-          the opaqueBackground extent of a renderer (DisplayObject) is com=
puted based on the cumulated extents of its children, not of its own width =
and height


In LabelItemRenderer, the padding around the renderer is big enough (16 px =
at 160 DPI) to compensate for this excess size for fonts not too large

However, in IconItemRender, the padding is set to 8px, so when the font siz=
e > 50, opaqueBackgorund overflows the item render size, and separator line=
s are masked.


There are many ways of fixing this :

-          increase the padding in IconItemRenderer, for 'reasonable' font =
sizes

-          modify the measure() to account for the excess size, so that opa=
queBackground never overflows.

-          etc...


What do you think ?

Maurice