You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@flex.apache.org by Maurice Amsellem <ma...@systar.com> on 2014/02/23 14:20:55 UTC
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, the bottom separators between items are not displayed.
After some hours of debugging, I finally found the cause, but don't know how to fix it, because it's related to AIR.
Here is the story, in short (details in the ticket):
- Mobile item renderers "opaqueBackground=color" property draws an opaque background behind item renderers, to make scrolling faster (no transparency).
- When StyleableTextField (text used in mobile renderers, inheriting from TextField) is given WxH size in flex, its actual extent will be around 15% larger
- the opaqueBackground extent of a renderer (DisplayObject) is computed 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 size > 50, opaqueBackgorund overflows the item render size, and separator lines 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 opaqueBackground never overflows.
- etc...
What do you think ?
Maurice
RE: RE:Need your help on problem with opaqueBackground
Posted by "piotr.zarzycki" <pi...@gmail.com>.
This is how it looks like.
IconItemRenderer properties:
fontSize=50, paddingLeft=40, width=100%, useOpaqueBackground="false"
http://images.devs-on.net/Image/pdtIXoVeU7er30ua-Obszar.png
-----
Flex/Air developer.
piotrzarzycki21@gmail.com
--
View this message in context: http://apache-flex-development.2333347.n4.nabble.com/Need-your-help-on-problem-with-opaqueBackground-tp34836p34983.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.
RE: RE:Need your help on problem with opaqueBackground
Posted by Maurice Amsellem <ma...@systar.com>.
OK, so truncation should occur, unless you increased the padding.
Maybe that's what you did.
Can you please attach a screenshot of the new rendering (after applying the fix)?
Maurice
BTW, I just committed change to use CSS for useDrawBackground.
You will be able to use it when the build is ready.
-----Message d'origine-----
De : piotr.zarzycki [mailto:piotrzarzycki21@gmail.com]
Envoyé : mardi 25 février 2014 11:06
À : dev@flex.apache.org
Objet : RE: RE:Need your help on problem with opaqueBackground
Sorry Maurice. My applicationDPI is set to 320 Embedded font size 40, 42 or 50 it's depends on view.
-----
Flex/Air developer.
piotrzarzycki21@gmail.com
--
View this message in context: http://apache-flex-development.2333347.n4.nabble.com/Need-your-help-on-problem-with-opaqueBackground-tp34836p34978.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.
RE: RE:Need your help on problem with opaqueBackground
Posted by "piotr.zarzycki" <pi...@gmail.com>.
Sorry Maurice. My applicationDPI is set to 320
Embedded font size 40, 42 or 50 it's depends on view.
-----
Flex/Air developer.
piotrzarzycki21@gmail.com
--
View this message in context: http://apache-flex-development.2333347.n4.nabble.com/Need-your-help-on-problem-with-opaqueBackground-tp34836p34978.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.
RE: RE:Need your help on problem with opaqueBackground
Posted by Maurice Amsellem <ma...@systar.com>.
Anyway, if you still want to change the separator color or behavior, you can rather easily override drawBorder in a custom render, and do what you like.
Maurice
-----Message d'origine-----
De : piotr.zarzycki [mailto:piotrzarzycki21@gmail.com]
Envoyé : mardi 25 février 2014 11:11
À : dev@flex.apache.org
Objet : RE: RE:Need your help on problem with opaqueBackground
Ok Never mind. I thought that we can simply set this bottomSeparatorColor from css for example and it do not depends on other thing.
-----
Flex/Air developer.
piotrzarzycki21@gmail.com
--
View this message in context: http://apache-flex-development.2333347.n4.nabble.com/Need-your-help-on-problem-with-opaqueBackground-tp34836p34979.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.
RE: RE:Need your help on problem with opaqueBackground
Posted by "piotr.zarzycki" <pi...@gmail.com>.
Ok Never mind. I thought that we can simply set this bottomSeparatorColor
from css for example and it do not depends on other thing.
-----
Flex/Air developer.
piotrzarzycki21@gmail.com
--
View this message in context: http://apache-flex-development.2333347.n4.nabble.com/Need-your-help-on-problem-with-opaqueBackground-tp34836p34979.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.
RE: RE:Need your help on problem with opaqueBackground
Posted by Maurice Amsellem <ma...@systar.com>.
Piotr, what font size are you using in your list ?
Regarding the separator css color:
Current separator are not really a color.
It is a shade of underneath renderer background color, which may vary depending on alternatingItemColors.
(see code below).
topSeparatorColor = 0xFFFFFF;
topSeparatorAlpha = .3;
bottomSeparatorColor = 0x000000;
bottomSeparatorAlpha = .3;
So IMO, it would be difficult to make it variable (through a css),
Because you will have to set top + bottom separator color+alpha for each alternating color.
That's a lot of css...
Or maybe I didn't understand well.
What kind of color would you set for the separator ?
-----Message d'origine-----
De : piotr.zarzycki [mailto:piotrzarzycki21@gmail.com]
Envoyé : mardi 25 février 2014 10:48
À : dev@flex.apache.org
Objet : RE: RE:Need your help on problem with opaqueBackground
I didn't notice any text truncation in our app.
Yes It would be really greate if I could set it in css. +1 for this.
Btw. Did you think also about my suggestion where we set also separators color in css? WDYT?
Piotr
-----
Flex/Air developer.
piotrzarzycki21@gmail.com
--
View this message in context: http://apache-flex-development.2333347.n4.nabble.com/Need-your-help-on-problem-with-opaqueBackground-tp34836p34976.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.
RE: RE:Need your help on problem with opaqueBackground
Posted by "piotr.zarzycki" <pi...@gmail.com>.
I didn't notice any text truncation in our app.
Yes It would be really greate if I could set it in css. +1 for this.
Btw. Did you think also about my suggestion where we set also separators
color in css? WDYT?
Piotr
-----
Flex/Air developer.
piotrzarzycki21@gmail.com
--
View this message in context: http://apache-flex-development.2333347.n4.nabble.com/Need-your-help-on-problem-with-opaqueBackground-tp34836p34976.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.
RE: RE:Need your help on problem with opaqueBackground
Posted by Maurice Amsellem <ma...@systar.com>.
You're welcome.
BTW, what font size and DPI are you using ? do you see any truncation of text bottom as described in :
https://issues.apache.org/jira/browse/FLEX-34112
https://issues.apache.org/jira/secure/attachment/12630918/truncated_text_when_using_font_50.jpg
Also, I realize that the "useOpaqueBackground" setting depends on the font size, which is a CSS and may vary depending on the device DPI.
So it would seem logical that the useOpaqueBackground be a css style as well.
WDYT?
Maurice
-----Message d'origine-----
De : piotr.zarzycki [mailto:piotrzarzycki21@gmail.com]
Envoyé : mardi 25 février 2014 09:32
À : dev@flex.apache.org
Objet : Re: RE:Need your help on problem with opaqueBackground
I've just checked it in real app and it looks fine. :) Thank you.
Piotr
-----
Flex/Air developer.
piotrzarzycki21@gmail.com
--
View this message in context: http://apache-flex-development.2333347.n4.nabble.com/Need-your-help-on-problem-with-opaqueBackground-tp34836p34971.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.
Re: RE:Need your help on problem with opaqueBackground
Posted by "piotr.zarzycki" <pi...@gmail.com>.
I've just checked it in real app and it looks fine. :) Thank you.
Piotr
-----
Flex/Air developer.
piotrzarzycki21@gmail.com
--
View this message in context: http://apache-flex-development.2333347.n4.nabble.com/Need-your-help-on-problem-with-opaqueBackground-tp34836p34971.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.
RE:Need your help on problem with opaqueBackground
Posted by Maurice Amsellem <ma...@systar.com>.
No, in the code , the top separator is not displayed for the first row. That's normal behavior
________________________________________
De : piotr.zarzycki [piotrzarzycki21@gmail.com]
Envoyé : mardi 25 février 2014 07:21
À : dev@flex.apache.org
Objet : RE: Need your help on problem with opaqueBackground
Maurice, Alex Thank you so much for fixing it!
I've tested it for now only on symulator I'll check it also today in my job.
I see one thing top separator in the first list is outside the view. In the
second list i have setted paddingTop="1". Maurice did you observe such
behaviour when you have been working on it ? We should probably see this top
separator.
Screen: http://images.devs-on.net/Image/50LBU8S62pQ5d4Sb-Obszar.png
Piotr
-----
Flex/Air developer.
piotrzarzycki21@gmail.com
--
View this message in context: http://apache-flex-development.2333347.n4.nabble.com/Need-your-help-on-problem-with-opaqueBackground-tp34836p34960.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.
RE: Need your help on problem with opaqueBackground
Posted by "piotr.zarzycki" <pi...@gmail.com>.
Maurice, Alex Thank you so much for fixing it!
I've tested it for now only on symulator I'll check it also today in my job.
I see one thing top separator in the first list is outside the view. In the
second list i have setted paddingTop="1". Maurice did you observe such
behaviour when you have been working on it ? We should probably see this top
separator.
Screen: http://images.devs-on.net/Image/50LBU8S62pQ5d4Sb-Obszar.png
Piotr
-----
Flex/Air developer.
piotrzarzycki21@gmail.com
--
View this message in context: http://apache-flex-development.2333347.n4.nabble.com/Need-your-help-on-problem-with-opaqueBackground-tp34836p34960.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.
RE: Need your help on problem with opaqueBackground
Posted by Maurice Amsellem <ma...@systar.com>.
Ok, implemented the "useOpaqueBackground" option. I put it at the renderer level, not the list, for simplicity.
So now there is no overflowing now:
https://issues.apache.org/jira/secure/attachment/12630785/07_fix_useOpaqueBackground_font_50px.jpg
However, since I removed all the previous code, the issue with "tightTextBounds" reappeared :
Current tightTextBounds calculation only considers the ascent, not ascent+descent.
So I will change the code to allow for either calculations (ascent or ascent+descent), so that it does not break existing layouts.
Maurice
-----Message d'origine-----
De : Maurice Amsellem [mailto:maurice.amsellem@systar.com]
Envoyé : lundi 24 février 2014 20:14
À : dev@flex.apache.org
Objet : RE: Need your help on problem with opaqueBackground
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:aharui@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.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 (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:aharui@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 <ma...@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
-----Message d'origine-----
De : Maurice Amsellem [mailto:maurice.amsellem@systar.com]
Envoyé : lundi 24 février 2014 10:57
À : 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 displayed.
_tightTextHeight = measuredTextSize.y - _tightTextTopOffset - bottomOffset; bottomOffset = StyleableTextField.TEXT_HEIGHT_PADDING/2 + metrics.descent [+ metrics.leading];
So it does not include the descent (and the debugging figures confirm that).
>I think the problem is in getTextTopOffset. It appears to be scanning a bitmap for the top of the glyphs! I thought there were lineMetrics information 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/text/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 and 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 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 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 with 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 compute the size of the opaque background.
Since one is much larger than the other, it's overflowing on the other renderers, 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 (including padding) and opaqueBackground extents match, so that it doesn't overflow.
Need to think about it more...
Maurice
-----Message d'origine-----
De : Alex Harui [mailto:aharui@adobe.com] Envoyé : lundi 24 février 2014 06:20 À : dev@flex.apache.org Objet : RE: Need your help on problem with 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 included descent if there are any descenders in the glyphs for the text to be displayed. 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 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 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 bitmap for the top of the glyphs! I thought there were lineMetrics information 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=true (regular r/o labels):
1) getPreferredBoundsHeight() returns tightTextHeight (which is basically the pixel height of "T" for single line text, and top pixel to baseline of last line for multineline )
The comment says " This is the height used for positioning text according to 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 - tightTextHeight) The comment says:
// we want to return the text field height without the top and bottom offsets
// (measuredTextSize.y - tightTextHeight) gives us the sum of top and bottom 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 the top pixel to the bottom pixel of the text, majored to make sure no clipping 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é : dimanche 23 février 2014 20:37
À : 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 approximations were somehow compensated by big enough paddings.
I have seen that useTightTextBound=true is for regural text and useTightTextBound=false for editable text (TextArea, TextInput).
So I will focus on the case where useTightTextBound = true, to minimize the impact.
This will probably break some Mustella mobile tests.
Maurice
-----Message d'origine-----
De : Alex Harui [mailto:aharui@adobe.com] Envoyé : dimanche 23 février 2014 20:10 À : 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.
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 the 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=true", 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 the same value, the text will get the same height:
layoutContents()
labelDisplay. setLayoutBoundsSize ( width, 36).
But in StylableTextField. setLayoutBoundsSize(), there is some logic regarding useTightTextBounds
And at the end it set text.height = 63 !! (instead of 36).
I don't know if SFT. setLayoutBoundSize (STF.getPreferredWidth() , STF.getPreferredBoundHeight) 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 = measuredTextSize.y - tightTextTopOffset - tightTextHeight;
// when clipping, allow gutter to be outside of height
// use 2x gutter (actual gutter is not part of tight text height)
// when newHeight==1, actual visible height==3 (1px + 1x gutter)
if (newHeight < tightTextHeight)
bottomOffset = StyleableTextField.TEXT_HEIGHT_PADDING;
// re-add the top and bottom offsets. (measuredTextSize.y - tightTextHeight) gives us
// the sum of top and bottom offsets
newHeight += (tightTextTopOffset + bottomOffset);
}
}
this.height = newHeight;
Maurice
-----Message d'origine-----
De : Alex Harui [mailto:aharui@adobe.com] Envoyé : dimanche 23 février 2014 17:45 À : 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% larger? What does transform.pixelbounds show? Does it have to do with the border 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, the bottom separators between items are not displayed.
After some hours of debugging, I finally found the cause, but don't know how to fix it, because it's related to AIR.
Here is the story, in short (details in the ticket):
- Mobile item renderers "opaqueBackground=color" property draws an opaque background behind item renderers, to make scrolling faster (no transparency).
- When StyleableTextField (text used in mobile renderers, inheriting from TextField) is given WxH size in flex, its actual extent will be around 15% larger
- the opaqueBackground extent of a renderer (DisplayObject) is computed 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 size > 50, opaqueBackgorund overflows the item render size, and separator lines 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 opaqueBackground never overflows.
- etc...
What do you think ?
Maurice
Re: Need your help on problem with opaqueBackground
Posted by Alex Harui <ah...@adobe.com>.
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" <ma...@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.amsellem@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:aharui@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 <ma...@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:aharui@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.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
>(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:aharui@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 <ma...@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]
RE: Need your help on problem with opaqueBackground
Posted by Maurice Amsellem <ma...@systar.com>.
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.amsellem@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:aharui@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 <ma...@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:aharui@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.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 (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:aharui@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 <ma...@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]
RE: Need your help on problem with opaqueBackground
Posted by Maurice Amsellem <ma...@systar.com>.
>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:aharui@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 <ma...@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:aharui@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.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 (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:aharui@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 <ma...@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
-----Message d'origine-----
De : Maurice Amsellem [mailto:maurice.amsellem@systar.com]
Envoyé : lundi 24 février 2014 10:57
À : 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 displayed.
_tightTextHeight = measuredTextSize.y - _tightTextTopOffset - bottomOffset; bottomOffset = StyleableTextField.TEXT_HEIGHT_PADDING/2 + metrics.descent [+ metrics.leading];
So it does not include the descent (and the debugging figures confirm that).
>I think the problem is in getTextTopOffset. It appears to be scanning a bitmap for the top of the glyphs! I thought there were lineMetrics information 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/text/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 and 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 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 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 with 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 compute the size of the opaque background.
Since one is much larger than the other, it's overflowing on the other renderers, 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 (including padding) and opaqueBackground extents match, so that it doesn't overflow.
Need to think about it more...
Maurice
-----Message d'origine-----
De : Alex Harui [mailto:aharui@adobe.com] Envoyé : lundi 24 février 2014 06:20 À : dev@flex.apache.org Objet : RE: Need your help on problem with 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 included descent if there are any descenders in the glyphs for the text to be displayed. 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 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 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 bitmap for the top of the glyphs! I thought there were lineMetrics information 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=true (regular r/o labels):
1) getPreferredBoundsHeight() returns tightTextHeight (which is basically the pixel height of "T" for single line text, and top pixel to baseline of last line for multineline )
The comment says " This is the height used for positioning text according to 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 - tightTextHeight) The comment says:
// we want to return the text field height without the top and bottom offsets
// (measuredTextSize.y - tightTextHeight) gives us the sum of top and bottom 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 the top pixel to the bottom pixel of the text, majored to make sure no clipping 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é : dimanche 23 février 2014 20:37
À : 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 approximations were somehow compensated by big enough paddings.
I have seen that useTightTextBound=true is for regural text and useTightTextBound=false for editable text (TextArea, TextInput).
So I will focus on the case where useTightTextBound = true, to minimize the impact.
This will probably break some Mustella mobile tests.
Maurice
-----Message d'origine-----
De : Alex Harui [mailto:aharui@adobe.com] Envoyé : dimanche 23 février 2014 20:10 À : 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.
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 the 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=true", 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 the same value, the text will get the same height:
layoutContents()
labelDisplay. setLayoutBoundsSize ( width, 36).
But in StylableTextField. setLayoutBoundsSize(), there is some logic regarding useTightTextBounds
And at the end it set text.height = 63 !! (instead of 36).
I don't know if SFT. setLayoutBoundSize (STF.getPreferredWidth() , STF.getPreferredBoundHeight) 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 = measuredTextSize.y - tightTextTopOffset - tightTextHeight;
// when clipping, allow gutter to be outside of height
// use 2x gutter (actual gutter is not part of tight text height)
// when newHeight==1, actual visible height==3 (1px + 1x gutter)
if (newHeight < tightTextHeight)
bottomOffset = StyleableTextField.TEXT_HEIGHT_PADDING;
// re-add the top and bottom offsets. (measuredTextSize.y - tightTextHeight) gives us
// the sum of top and bottom offsets
newHeight += (tightTextTopOffset + bottomOffset);
}
}
this.height = newHeight;
Maurice
-----Message d'origine-----
De : Alex Harui [mailto:aharui@adobe.com] Envoyé : dimanche 23 février 2014 17:45 À : 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% larger? What does transform.pixelbounds show? Does it have to do with the border 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, the bottom separators between items are not displayed.
After some hours of debugging, I finally found the cause, but don't know how to fix it, because it's related to AIR.
Here is the story, in short (details in the ticket):
- Mobile item renderers "opaqueBackground=color" property draws an opaque background behind item renderers, to make scrolling faster (no transparency).
- When StyleableTextField (text used in mobile renderers, inheriting from TextField) is given WxH size in flex, its actual extent will be around 15% larger
- the opaqueBackground extent of a renderer (DisplayObject) is computed 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 size > 50, opaqueBackgorund overflows the item render size, and separator lines 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 opaqueBackground never overflows.
- etc...
What do you think ?
Maurice
RE: Need your help on problem with opaqueBackground
Posted by Alex Harui <ah...@adobe.com>.
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 <ma...@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:aharui@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.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 (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:aharui@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 <ma...@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
-----Message d'origine-----
De : Maurice Amsellem [mailto:maurice.amsellem@systar.com]
Envoyé : lundi 24 février 2014 10:57
À : 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 displayed.
_tightTextHeight = measuredTextSize.y - _tightTextTopOffset - bottomOffset; bottomOffset = StyleableTextField.TEXT_HEIGHT_PADDING/2 + metrics.descent [+ metrics.leading];
So it does not include the descent (and the debugging figures confirm that).
>I think the problem is in getTextTopOffset. It appears to be scanning a bitmap for the top of the glyphs! I thought there were lineMetrics information 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/text/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 and 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 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 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 with 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 compute the size of the opaque background.
Since one is much larger than the other, it's overflowing on the other renderers, 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 (including padding) and opaqueBackground extents match, so that it doesn't overflow.
Need to think about it more...
Maurice
-----Message d'origine-----
De : Alex Harui [mailto:aharui@adobe.com] Envoyé : lundi 24 février 2014 06:20 À : dev@flex.apache.org Objet : RE: Need your help on problem with 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 included descent if there are any descenders in the glyphs for the text to be displayed. 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 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 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 bitmap for the top of the glyphs! I thought there were lineMetrics information 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=true (regular r/o labels):
1) getPreferredBoundsHeight() returns tightTextHeight (which is basically the pixel height of "T" for single line text, and top pixel to baseline of last line for multineline )
The comment says " This is the height used for positioning text according to 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 - tightTextHeight) The comment says:
// we want to return the text field height without the top and bottom offsets
// (measuredTextSize.y - tightTextHeight) gives us the sum of top and bottom 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 the top pixel to the bottom pixel of the text, majored to make sure no clipping 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é : dimanche 23 février 2014 20:37
À : 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 approximations were somehow compensated by big enough paddings.
I have seen that useTightTextBound=true is for regural text and useTightTextBound=false for editable text (TextArea, TextInput).
So I will focus on the case where useTightTextBound = true, to minimize the impact.
This will probably break some Mustella mobile tests.
Maurice
-----Message d'origine-----
De : Alex Harui [mailto:aharui@adobe.com] Envoyé : dimanche 23 février 2014 20:10 À : 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.
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 the 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=true", 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 the same value, the text will get the same height:
layoutContents()
labelDisplay. setLayoutBoundsSize ( width, 36).
But in StylableTextField. setLayoutBoundsSize(), there is some logic regarding useTightTextBounds
And at the end it set text.height = 63 !! (instead of 36).
I don't know if SFT. setLayoutBoundSize (STF.getPreferredWidth() , STF.getPreferredBoundHeight) 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 = measuredTextSize.y - tightTextTopOffset - tightTextHeight;
// when clipping, allow gutter to be outside of height
// use 2x gutter (actual gutter is not part of tight text height)
// when newHeight==1, actual visible height==3 (1px + 1x gutter)
if (newHeight < tightTextHeight)
bottomOffset = StyleableTextField.TEXT_HEIGHT_PADDING;
// re-add the top and bottom offsets. (measuredTextSize.y - tightTextHeight) gives us
// the sum of top and bottom offsets
newHeight += (tightTextTopOffset + bottomOffset);
}
}
this.height = newHeight;
Maurice
-----Message d'origine-----
De : Alex Harui [mailto:aharui@adobe.com] Envoyé : dimanche 23 février 2014 17:45 À : 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% larger? What does transform.pixelbounds show? Does it have to do with the border 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, the bottom separators between items are not displayed.
After some hours of debugging, I finally found the cause, but don't know how to fix it, because it's related to AIR.
Here is the story, in short (details in the ticket):
- Mobile item renderers "opaqueBackground=color" property draws an opaque background behind item renderers, to make scrolling faster (no transparency).
- When StyleableTextField (text used in mobile renderers, inheriting from TextField) is given WxH size in flex, its actual extent will be around 15% larger
- the opaqueBackground extent of a renderer (DisplayObject) is computed 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 size > 50, opaqueBackgorund overflows the item render size, and separator lines 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 opaqueBackground never overflows.
- etc...
What do you think ?
Maurice
RE: Need your help on problem with opaqueBackground
Posted by Maurice Amsellem <ma...@systar.com>.
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:aharui@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.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 (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:aharui@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 <ma...@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
-----Message d'origine-----
De : Maurice Amsellem [mailto:maurice.amsellem@systar.com]
Envoyé : lundi 24 février 2014 10:57
À : 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 displayed.
_tightTextHeight = measuredTextSize.y - _tightTextTopOffset - bottomOffset; bottomOffset = StyleableTextField.TEXT_HEIGHT_PADDING/2 + metrics.descent [+ metrics.leading];
So it does not include the descent (and the debugging figures confirm that).
>I think the problem is in getTextTopOffset. It appears to be scanning a bitmap for the top of the glyphs! I thought there were lineMetrics information 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/text/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 and 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 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 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 with 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 compute the size of the opaque background.
Since one is much larger than the other, it's overflowing on the other renderers, 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 (including padding) and opaqueBackground extents match, so that it doesn't overflow.
Need to think about it more...
Maurice
-----Message d'origine-----
De : Alex Harui [mailto:aharui@adobe.com] Envoyé : lundi 24 février 2014 06:20 À : dev@flex.apache.org Objet : RE: Need your help on problem with 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 included descent if there are any descenders in the glyphs for the text to be displayed. 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 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 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 bitmap for the top of the glyphs! I thought there were lineMetrics information 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=true (regular r/o labels):
1) getPreferredBoundsHeight() returns tightTextHeight (which is basically the pixel height of "T" for single line text, and top pixel to baseline of last line for multineline )
The comment says " This is the height used for positioning text according to 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 - tightTextHeight) The comment says:
// we want to return the text field height without the top and bottom offsets
// (measuredTextSize.y - tightTextHeight) gives us the sum of top and bottom 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 the top pixel to the bottom pixel of the text, majored to make sure no clipping 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é : dimanche 23 février 2014 20:37
À : 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 approximations were somehow compensated by big enough paddings.
I have seen that useTightTextBound=true is for regural text and useTightTextBound=false for editable text (TextArea, TextInput).
So I will focus on the case where useTightTextBound = true, to minimize the impact.
This will probably break some Mustella mobile tests.
Maurice
-----Message d'origine-----
De : Alex Harui [mailto:aharui@adobe.com] Envoyé : dimanche 23 février 2014 20:10 À : 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.
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 the 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=true", 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 the same value, the text will get the same height:
layoutContents()
labelDisplay. setLayoutBoundsSize ( width, 36).
But in StylableTextField. setLayoutBoundsSize(), there is some logic regarding useTightTextBounds
And at the end it set text.height = 63 !! (instead of 36).
I don't know if SFT. setLayoutBoundSize (STF.getPreferredWidth() , STF.getPreferredBoundHeight) 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 = measuredTextSize.y - tightTextTopOffset - tightTextHeight;
// when clipping, allow gutter to be outside of height
// use 2x gutter (actual gutter is not part of tight text height)
// when newHeight==1, actual visible height==3 (1px + 1x gutter)
if (newHeight < tightTextHeight)
bottomOffset = StyleableTextField.TEXT_HEIGHT_PADDING;
// re-add the top and bottom offsets. (measuredTextSize.y - tightTextHeight) gives us
// the sum of top and bottom offsets
newHeight += (tightTextTopOffset + bottomOffset);
}
}
this.height = newHeight;
Maurice
-----Message d'origine-----
De : Alex Harui [mailto:aharui@adobe.com] Envoyé : dimanche 23 février 2014 17:45 À : 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% larger? What does transform.pixelbounds show? Does it have to do with the border 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, the bottom separators between items are not displayed.
After some hours of debugging, I finally found the cause, but don't know how to fix it, because it's related to AIR.
Here is the story, in short (details in the ticket):
- Mobile item renderers "opaqueBackground=color" property draws an opaque background behind item renderers, to make scrolling faster (no transparency).
- When StyleableTextField (text used in mobile renderers, inheriting from TextField) is given WxH size in flex, its actual extent will be around 15% larger
- the opaqueBackground extent of a renderer (DisplayObject) is computed 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 size > 50, opaqueBackgorund overflows the item render size, and separator lines 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 opaqueBackground never overflows.
- etc...
What do you think ?
Maurice
RE: Need your help on problem with opaqueBackground
Posted by Maurice Amsellem <ma...@systar.com>.
>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.
In fact, when the font gets large, I will have to extend the default padding to contain the mandatory space above the text (= tighTextTopOffset).
Do you consider this as " textfields extend beyond the desired boundaries of the renderer" ?
Maurice
-----Message d'origine-----
De : Alex Harui [mailto:aharui@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.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 (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:aharui@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 <ma...@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
-----Message d'origine-----
De : Maurice Amsellem [mailto:maurice.amsellem@systar.com]
Envoyé : lundi 24 février 2014 10:57
À : 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 displayed.
_tightTextHeight = measuredTextSize.y - _tightTextTopOffset - bottomOffset; bottomOffset = StyleableTextField.TEXT_HEIGHT_PADDING/2 + metrics.descent [+ metrics.leading];
So it does not include the descent (and the debugging figures confirm that).
>I think the problem is in getTextTopOffset. It appears to be scanning a bitmap for the top of the glyphs! I thought there were lineMetrics information 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/text/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 and 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 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 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 with 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 compute the size of the opaque background.
Since one is much larger than the other, it's overflowing on the other renderers, 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 (including padding) and opaqueBackground extents match, so that it doesn't overflow.
Need to think about it more...
Maurice
-----Message d'origine-----
De : Alex Harui [mailto:aharui@adobe.com] Envoyé : lundi 24 février 2014 06:20 À : dev@flex.apache.org Objet : RE: Need your help on problem with 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 included descent if there are any descenders in the glyphs for the text to be displayed. 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 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 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 bitmap for the top of the glyphs! I thought there were lineMetrics information 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=true (regular r/o labels):
1) getPreferredBoundsHeight() returns tightTextHeight (which is basically the pixel height of "T" for single line text, and top pixel to baseline of last line for multineline )
The comment says " This is the height used for positioning text according to 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 - tightTextHeight) The comment says:
// we want to return the text field height without the top and bottom offsets
// (measuredTextSize.y - tightTextHeight) gives us the sum of top and bottom 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 the top pixel to the bottom pixel of the text, majored to make sure no clipping 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é : dimanche 23 février 2014 20:37
À : 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 approximations were somehow compensated by big enough paddings.
I have seen that useTightTextBound=true is for regural text and useTightTextBound=false for editable text (TextArea, TextInput).
So I will focus on the case where useTightTextBound = true, to minimize the impact.
This will probably break some Mustella mobile tests.
Maurice
-----Message d'origine-----
De : Alex Harui [mailto:aharui@adobe.com] Envoyé : dimanche 23 février 2014 20:10 À : 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.
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 the 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=true", 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 the same value, the text will get the same height:
layoutContents()
labelDisplay. setLayoutBoundsSize ( width, 36).
But in StylableTextField. setLayoutBoundsSize(), there is some logic regarding useTightTextBounds
And at the end it set text.height = 63 !! (instead of 36).
I don't know if SFT. setLayoutBoundSize (STF.getPreferredWidth() , STF.getPreferredBoundHeight) 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 = measuredTextSize.y - tightTextTopOffset - tightTextHeight;
// when clipping, allow gutter to be outside of height
// use 2x gutter (actual gutter is not part of tight text height)
// when newHeight==1, actual visible height==3 (1px + 1x gutter)
if (newHeight < tightTextHeight)
bottomOffset = StyleableTextField.TEXT_HEIGHT_PADDING;
// re-add the top and bottom offsets. (measuredTextSize.y - tightTextHeight) gives us
// the sum of top and bottom offsets
newHeight += (tightTextTopOffset + bottomOffset);
}
}
this.height = newHeight;
Maurice
-----Message d'origine-----
De : Alex Harui [mailto:aharui@adobe.com] Envoyé : dimanche 23 février 2014 17:45 À : 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% larger? What does transform.pixelbounds show? Does it have to do with the border 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, the bottom separators between items are not displayed.
After some hours of debugging, I finally found the cause, but don't know how to fix it, because it's related to AIR.
Here is the story, in short (details in the ticket):
- Mobile item renderers "opaqueBackground=color" property draws an opaque background behind item renderers, to make scrolling faster (no transparency).
- When StyleableTextField (text used in mobile renderers, inheriting from TextField) is given WxH size in flex, its actual extent will be around 15% larger
- the opaqueBackground extent of a renderer (DisplayObject) is computed 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 size > 50, opaqueBackgorund overflows the item render size, and separator lines 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 opaqueBackground never overflows.
- etc...
What do you think ?
Maurice
RE: Need your help on problem with opaqueBackground
Posted by Alex Harui <ah...@adobe.com>.
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.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 (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:aharui@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 <ma...@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
-----Message d'origine-----
De : Maurice Amsellem [mailto:maurice.amsellem@systar.com]
Envoyé : lundi 24 février 2014 10:57
À : 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 displayed.
_tightTextHeight = measuredTextSize.y - _tightTextTopOffset - bottomOffset; bottomOffset = StyleableTextField.TEXT_HEIGHT_PADDING/2 + metrics.descent [+ metrics.leading];
So it does not include the descent (and the debugging figures confirm that).
>I think the problem is in getTextTopOffset. It appears to be scanning a bitmap for the top of the glyphs! I thought there were lineMetrics information 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/text/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 and 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 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 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 with 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 compute the size of the opaque background.
Since one is much larger than the other, it's overflowing on the other renderers, 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 (including padding) and opaqueBackground extents match, so that it doesn't overflow.
Need to think about it more...
Maurice
-----Message d'origine-----
De : Alex Harui [mailto:aharui@adobe.com] Envoyé : lundi 24 février 2014 06:20 À : dev@flex.apache.org Objet : RE: Need your help on problem with 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 included descent if there are any descenders in the glyphs for the text to be displayed. 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 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 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 bitmap for the top of the glyphs! I thought there were lineMetrics information 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=true (regular r/o labels):
1) getPreferredBoundsHeight() returns tightTextHeight (which is basically the pixel height of "T" for single line text, and top pixel to baseline of last line for multineline )
The comment says " This is the height used for positioning text according to 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 - tightTextHeight) The comment says:
// we want to return the text field height without the top and bottom offsets
// (measuredTextSize.y - tightTextHeight) gives us the sum of top and bottom 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 the top pixel to the bottom pixel of the text, majored to make sure no clipping 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é : dimanche 23 février 2014 20:37
À : 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 approximations were somehow compensated by big enough paddings.
I have seen that useTightTextBound=true is for regural text and useTightTextBound=false for editable text (TextArea, TextInput).
So I will focus on the case where useTightTextBound = true, to minimize the impact.
This will probably break some Mustella mobile tests.
Maurice
-----Message d'origine-----
De : Alex Harui [mailto:aharui@adobe.com] Envoyé : dimanche 23 février 2014 20:10 À : 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.
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 the 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=true", 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 the same value, the text will get the same height:
layoutContents()
labelDisplay. setLayoutBoundsSize ( width, 36).
But in StylableTextField. setLayoutBoundsSize(), there is some logic regarding useTightTextBounds
And at the end it set text.height = 63 !! (instead of 36).
I don't know if SFT. setLayoutBoundSize (STF.getPreferredWidth() , STF.getPreferredBoundHeight) 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 = measuredTextSize.y - tightTextTopOffset - tightTextHeight;
// when clipping, allow gutter to be outside of height
// use 2x gutter (actual gutter is not part of tight text height)
// when newHeight==1, actual visible height==3 (1px + 1x gutter)
if (newHeight < tightTextHeight)
bottomOffset = StyleableTextField.TEXT_HEIGHT_PADDING;
// re-add the top and bottom offsets. (measuredTextSize.y - tightTextHeight) gives us
// the sum of top and bottom offsets
newHeight += (tightTextTopOffset + bottomOffset);
}
}
this.height = newHeight;
Maurice
-----Message d'origine-----
De : Alex Harui [mailto:aharui@adobe.com] Envoyé : dimanche 23 février 2014 17:45 À : 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% larger? What does transform.pixelbounds show? Does it have to do with the border 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, the bottom separators between items are not displayed.
After some hours of debugging, I finally found the cause, but don't know how to fix it, because it's related to AIR.
Here is the story, in short (details in the ticket):
- Mobile item renderers "opaqueBackground=color" property draws an opaque background behind item renderers, to make scrolling faster (no transparency).
- When StyleableTextField (text used in mobile renderers, inheriting from TextField) is given WxH size in flex, its actual extent will be around 15% larger
- the opaqueBackground extent of a renderer (DisplayObject) is computed 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 size > 50, opaqueBackgorund overflows the item render size, and separator lines 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 opaqueBackground never overflows.
- etc...
What do you think ?
Maurice
RE: Need your help on problem with opaqueBackground
Posted by Maurice Amsellem <ma...@systar.com>.
>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:aharui@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 <ma...@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
-----Message d'origine-----
De : Maurice Amsellem [mailto:maurice.amsellem@systar.com]
Envoyé : lundi 24 février 2014 10:57
À : 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 displayed.
_tightTextHeight = measuredTextSize.y - _tightTextTopOffset - bottomOffset; bottomOffset = StyleableTextField.TEXT_HEIGHT_PADDING/2 + metrics.descent [+ metrics.leading];
So it does not include the descent (and the debugging figures confirm that).
>I think the problem is in getTextTopOffset. It appears to be scanning a bitmap for the top of the glyphs! I thought there were lineMetrics information 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/text/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 and 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 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 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 with 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 compute the size of the opaque background.
Since one is much larger than the other, it's overflowing on the other renderers, 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 (including padding) and opaqueBackground extents match, so that it doesn't overflow.
Need to think about it more...
Maurice
-----Message d'origine-----
De : Alex Harui [mailto:aharui@adobe.com] Envoyé : lundi 24 février 2014 06:20 À : dev@flex.apache.org Objet : RE: Need your help on problem with 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 included descent if there are any descenders in the glyphs for the text to be displayed. 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 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 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 bitmap for the top of the glyphs! I thought there were lineMetrics information 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=true (regular r/o labels):
1) getPreferredBoundsHeight() returns tightTextHeight (which is basically the pixel height of "T" for single line text, and top pixel to baseline of last line for multineline )
The comment says " This is the height used for positioning text according to 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 - tightTextHeight) The comment says:
// we want to return the text field height without the top and bottom offsets
// (measuredTextSize.y - tightTextHeight) gives us the sum of top and bottom 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 the top pixel to the bottom pixel of the text, majored to make sure no clipping 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é : dimanche 23 février 2014 20:37
À : 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 approximations were somehow compensated by big enough paddings.
I have seen that useTightTextBound=true is for regural text and useTightTextBound=false for editable text (TextArea, TextInput).
So I will focus on the case where useTightTextBound = true, to minimize the impact.
This will probably break some Mustella mobile tests.
Maurice
-----Message d'origine-----
De : Alex Harui [mailto:aharui@adobe.com] Envoyé : dimanche 23 février 2014 20:10 À : 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.
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 the 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=true", 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 the same value, the text will get the same height:
layoutContents()
labelDisplay. setLayoutBoundsSize ( width, 36).
But in StylableTextField. setLayoutBoundsSize(), there is some logic regarding useTightTextBounds
And at the end it set text.height = 63 !! (instead of 36).
I don't know if SFT. setLayoutBoundSize (STF.getPreferredWidth() , STF.getPreferredBoundHeight) 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 = measuredTextSize.y - tightTextTopOffset - tightTextHeight;
// when clipping, allow gutter to be outside of height
// use 2x gutter (actual gutter is not part of tight text height)
// when newHeight==1, actual visible height==3 (1px + 1x gutter)
if (newHeight < tightTextHeight)
bottomOffset = StyleableTextField.TEXT_HEIGHT_PADDING;
// re-add the top and bottom offsets. (measuredTextSize.y - tightTextHeight) gives us
// the sum of top and bottom offsets
newHeight += (tightTextTopOffset + bottomOffset);
}
}
this.height = newHeight;
Maurice
-----Message d'origine-----
De : Alex Harui [mailto:aharui@adobe.com] Envoyé : dimanche 23 février 2014 17:45 À : 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% larger? What does transform.pixelbounds show? Does it have to do with the border 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, the bottom separators between items are not displayed.
After some hours of debugging, I finally found the cause, but don't know how to fix it, because it's related to AIR.
Here is the story, in short (details in the ticket):
- Mobile item renderers "opaqueBackground=color" property draws an opaque background behind item renderers, to make scrolling faster (no transparency).
- When StyleableTextField (text used in mobile renderers, inheriting from TextField) is given WxH size in flex, its actual extent will be around 15% larger
- the opaqueBackground extent of a renderer (DisplayObject) is computed 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 size > 50, opaqueBackgorund overflows the item render size, and separator lines 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 opaqueBackground never overflows.
- etc...
What do you think ?
Maurice
RE: Need your help on problem with opaqueBackground
Posted by Alex Harui <ah...@adobe.com>.
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 <ma...@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
-----Message d'origine-----
De : Maurice Amsellem [mailto:maurice.amsellem@systar.com]
Envoyé : lundi 24 février 2014 10:57
À : 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 displayed.
_tightTextHeight = measuredTextSize.y - _tightTextTopOffset - bottomOffset; bottomOffset = StyleableTextField.TEXT_HEIGHT_PADDING/2 + metrics.descent [+ metrics.leading];
So it does not include the descent (and the debugging figures confirm that).
>I think the problem is in getTextTopOffset. It appears to be scanning a bitmap for the top of the glyphs! I thought there were lineMetrics information 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/text/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 and 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 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 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 with 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 compute the size of the opaque background.
Since one is much larger than the other, it's overflowing on the other renderers, 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 (including padding) and opaqueBackground extents match, so that it doesn't overflow.
Need to think about it more...
Maurice
-----Message d'origine-----
De : Alex Harui [mailto:aharui@adobe.com] Envoyé : lundi 24 février 2014 06:20 À : dev@flex.apache.org Objet : RE: Need your help on problem with 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 included descent if there are any descenders in the glyphs for the text to be displayed. 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 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 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 bitmap for the top of the glyphs! I thought there were lineMetrics information 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=true (regular r/o labels):
1) getPreferredBoundsHeight() returns tightTextHeight (which is basically the pixel height of "T" for single line text, and top pixel to baseline of last line for multineline )
The comment says " This is the height used for positioning text according to 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 - tightTextHeight) The comment says:
// we want to return the text field height without the top and bottom offsets
// (measuredTextSize.y - tightTextHeight) gives us the sum of top and bottom 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 the top pixel to the bottom pixel of the text, majored to make sure no clipping 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é : dimanche 23 février 2014 20:37
À : 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 approximations were somehow compensated by big enough paddings.
I have seen that useTightTextBound=true is for regural text and useTightTextBound=false for editable text (TextArea, TextInput).
So I will focus on the case where useTightTextBound = true, to minimize the impact.
This will probably break some Mustella mobile tests.
Maurice
-----Message d'origine-----
De : Alex Harui [mailto:aharui@adobe.com] Envoyé : dimanche 23 février 2014 20:10 À : 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.
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 the 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=true", 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 the same value, the text will get the same height:
layoutContents()
labelDisplay. setLayoutBoundsSize ( width, 36).
But in StylableTextField. setLayoutBoundsSize(), there is some logic regarding useTightTextBounds
And at the end it set text.height = 63 !! (instead of 36).
I don't know if SFT. setLayoutBoundSize (STF.getPreferredWidth() , STF.getPreferredBoundHeight) 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 = measuredTextSize.y - tightTextTopOffset - tightTextHeight;
// when clipping, allow gutter to be outside of height
// use 2x gutter (actual gutter is not part of tight text height)
// when newHeight==1, actual visible height==3 (1px + 1x gutter)
if (newHeight < tightTextHeight)
bottomOffset = StyleableTextField.TEXT_HEIGHT_PADDING;
// re-add the top and bottom offsets. (measuredTextSize.y - tightTextHeight) gives us
// the sum of top and bottom offsets
newHeight += (tightTextTopOffset + bottomOffset);
}
}
this.height = newHeight;
Maurice
-----Message d'origine-----
De : Alex Harui [mailto:aharui@adobe.com] Envoyé : dimanche 23 février 2014 17:45 À : 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% larger? What does transform.pixelbounds show? Does it have to do with the border 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, the bottom separators between items are not displayed.
After some hours of debugging, I finally found the cause, but don't know how to fix it, because it's related to AIR.
Here is the story, in short (details in the ticket):
- Mobile item renderers "opaqueBackground=color" property draws an opaque background behind item renderers, to make scrolling faster (no transparency).
- When StyleableTextField (text used in mobile renderers, inheriting from TextField) is given WxH size in flex, its actual extent will be around 15% larger
- the opaqueBackground extent of a renderer (DisplayObject) is computed 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 size > 50, opaqueBackgorund overflows the item render size, and separator lines 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 opaqueBackground never overflows.
- etc...
What do you think ?
Maurice
RE: Need your help on problem with opaqueBackground
Posted by Maurice Amsellem <ma...@systar.com>.
Funny:
https://issues.apache.org/jira/browse/FLEX-34110
So it looks like I will have to fix this one as well ;-)
Maurice
-----Message d'origine-----
De : Maurice Amsellem [mailto:maurice.amsellem@systar.com]
Envoyé : lundi 24 février 2014 12:57
À : dev@flex.apache.org
Objet : RE: Need your help on problem with opaqueBackground
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
-----Message d'origine-----
De : Maurice Amsellem [mailto:maurice.amsellem@systar.com]
Envoyé : lundi 24 février 2014 10:57
À : 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 displayed.
_tightTextHeight = measuredTextSize.y - _tightTextTopOffset - bottomOffset; bottomOffset = StyleableTextField.TEXT_HEIGHT_PADDING/2 + metrics.descent [+ metrics.leading];
So it does not include the descent (and the debugging figures confirm that).
>I think the problem is in getTextTopOffset. It appears to be scanning a bitmap for the top of the glyphs! I thought there were lineMetrics information 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/text/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 and 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 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 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 with 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 compute the size of the opaque background.
Since one is much larger than the other, it's overflowing on the other renderers, 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 (including padding) and opaqueBackground extents match, so that it doesn't overflow.
Need to think about it more...
Maurice
-----Message d'origine-----
De : Alex Harui [mailto:aharui@adobe.com] Envoyé : lundi 24 février 2014 06:20 À : dev@flex.apache.org Objet : RE: Need your help on problem with 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 included descent if there are any descenders in the glyphs for the text to be displayed. 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 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 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 bitmap for the top of the glyphs! I thought there were lineMetrics information 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=true (regular r/o labels):
1) getPreferredBoundsHeight() returns tightTextHeight (which is basically the pixel height of "T" for single line text, and top pixel to baseline of last line for multineline )
The comment says " This is the height used for positioning text according to 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 - tightTextHeight) The comment says:
// we want to return the text field height without the top and bottom offsets
// (measuredTextSize.y - tightTextHeight) gives us the sum of top and bottom 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 the top pixel to the bottom pixel of the text, majored to make sure no clipping 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é : dimanche 23 février 2014 20:37
À : 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 approximations were somehow compensated by big enough paddings.
I have seen that useTightTextBound=true is for regural text and useTightTextBound=false for editable text (TextArea, TextInput).
So I will focus on the case where useTightTextBound = true, to minimize the impact.
This will probably break some Mustella mobile tests.
Maurice
-----Message d'origine-----
De : Alex Harui [mailto:aharui@adobe.com] Envoyé : dimanche 23 février 2014 20:10 À : 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.
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 the 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=true", 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 the same value, the text will get the same height:
layoutContents()
labelDisplay. setLayoutBoundsSize ( width, 36).
But in StylableTextField. setLayoutBoundsSize(), there is some logic regarding useTightTextBounds
And at the end it set text.height = 63 !! (instead of 36).
I don't know if SFT. setLayoutBoundSize (STF.getPreferredWidth() , STF.getPreferredBoundHeight) 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 = measuredTextSize.y - tightTextTopOffset - tightTextHeight;
// when clipping, allow gutter to be outside of height
// use 2x gutter (actual gutter is not part of tight text height)
// when newHeight==1, actual visible height==3 (1px + 1x gutter)
if (newHeight < tightTextHeight)
bottomOffset = StyleableTextField.TEXT_HEIGHT_PADDING;
// re-add the top and bottom offsets. (measuredTextSize.y - tightTextHeight) gives us
// the sum of top and bottom offsets
newHeight += (tightTextTopOffset + bottomOffset);
}
}
this.height = newHeight;
Maurice
-----Message d'origine-----
De : Alex Harui [mailto:aharui@adobe.com] Envoyé : dimanche 23 février 2014 17:45 À : 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% larger? What does transform.pixelbounds show? Does it have to do with the border 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, the bottom separators between items are not displayed.
After some hours of debugging, I finally found the cause, but don't know how to fix it, because it's related to AIR.
Here is the story, in short (details in the ticket):
- Mobile item renderers "opaqueBackground=color" property draws an opaque background behind item renderers, to make scrolling faster (no transparency).
- When StyleableTextField (text used in mobile renderers, inheriting from TextField) is given WxH size in flex, its actual extent will be around 15% larger
- the opaqueBackground extent of a renderer (DisplayObject) is computed 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 size > 50, opaqueBackgorund overflows the item render size, and separator lines 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 opaqueBackground never overflows.
- etc...
What do you think ?
Maurice
RE: Need your help on problem with opaqueBackground
Posted by Maurice Amsellem <ma...@systar.com>.
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
-----Message d'origine-----
De : Maurice Amsellem [mailto:maurice.amsellem@systar.com]
Envoyé : lundi 24 février 2014 10:57
À : 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 displayed.
_tightTextHeight = measuredTextSize.y - _tightTextTopOffset - bottomOffset; bottomOffset = StyleableTextField.TEXT_HEIGHT_PADDING/2 + metrics.descent [+ metrics.leading];
So it does not include the descent (and the debugging figures confirm that).
>I think the problem is in getTextTopOffset. It appears to be scanning a bitmap for the top of the glyphs! I thought there were lineMetrics information 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/text/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 and 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 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 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 with 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 compute the size of the opaque background.
Since one is much larger than the other, it's overflowing on the other renderers, 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 (including padding) and opaqueBackground extents match, so that it doesn't overflow.
Need to think about it more...
Maurice
-----Message d'origine-----
De : Alex Harui [mailto:aharui@adobe.com] Envoyé : lundi 24 février 2014 06:20 À : dev@flex.apache.org Objet : RE: Need your help on problem with 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 included descent if there are any descenders in the glyphs for the text to be displayed. 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 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 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 bitmap for the top of the glyphs! I thought there were lineMetrics information 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=true (regular r/o labels):
1) getPreferredBoundsHeight() returns tightTextHeight (which is basically the pixel height of "T" for single line text, and top pixel to baseline of last line for multineline )
The comment says " This is the height used for positioning text according to 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 - tightTextHeight) The comment says:
// we want to return the text field height without the top and bottom offsets
// (measuredTextSize.y - tightTextHeight) gives us the sum of top and bottom 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 the top pixel to the bottom pixel of the text, majored to make sure no clipping 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é : dimanche 23 février 2014 20:37
À : 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 approximations were somehow compensated by big enough paddings.
I have seen that useTightTextBound=true is for regural text and useTightTextBound=false for editable text (TextArea, TextInput).
So I will focus on the case where useTightTextBound = true, to minimize the impact.
This will probably break some Mustella mobile tests.
Maurice
-----Message d'origine-----
De : Alex Harui [mailto:aharui@adobe.com] Envoyé : dimanche 23 février 2014 20:10 À : 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.
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 the 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=true", 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 the same value, the text will get the same height:
layoutContents()
labelDisplay. setLayoutBoundsSize ( width, 36).
But in StylableTextField. setLayoutBoundsSize(), there is some logic regarding useTightTextBounds
And at the end it set text.height = 63 !! (instead of 36).
I don't know if SFT. setLayoutBoundSize (STF.getPreferredWidth() , STF.getPreferredBoundHeight) 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 = measuredTextSize.y - tightTextTopOffset - tightTextHeight;
// when clipping, allow gutter to be outside of height
// use 2x gutter (actual gutter is not part of tight text height)
// when newHeight==1, actual visible height==3 (1px + 1x gutter)
if (newHeight < tightTextHeight)
bottomOffset = StyleableTextField.TEXT_HEIGHT_PADDING;
// re-add the top and bottom offsets. (measuredTextSize.y - tightTextHeight) gives us
// the sum of top and bottom offsets
newHeight += (tightTextTopOffset + bottomOffset);
}
}
this.height = newHeight;
Maurice
-----Message d'origine-----
De : Alex Harui [mailto:aharui@adobe.com] Envoyé : dimanche 23 février 2014 17:45 À : 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% larger? What does transform.pixelbounds show? Does it have to do with the border 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, the bottom separators between items are not displayed.
After some hours of debugging, I finally found the cause, but don't know how to fix it, because it's related to AIR.
Here is the story, in short (details in the ticket):
- Mobile item renderers "opaqueBackground=color" property draws an opaque background behind item renderers, to make scrolling faster (no transparency).
- When StyleableTextField (text used in mobile renderers, inheriting from TextField) is given WxH size in flex, its actual extent will be around 15% larger
- the opaqueBackground extent of a renderer (DisplayObject) is computed 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 size > 50, opaqueBackgorund overflows the item render size, and separator lines 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 opaqueBackground never overflows.
- etc...
What do you think ?
Maurice
RE: Need your help on problem with opaqueBackground
Posted by Maurice Amsellem <ma...@systar.com>.
>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 displayed.
_tightTextHeight = measuredTextSize.y - _tightTextTopOffset - bottomOffset;
bottomOffset = StyleableTextField.TEXT_HEIGHT_PADDING/2 + metrics.descent [+ metrics.leading];
So it does not include the descent (and the debugging figures confirm that).
>I think the problem is in getTextTopOffset. It appears to be scanning a bitmap for the top of the glyphs! I thought there were lineMetrics information 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/text/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 and 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 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 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 with 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 compute the size of the opaque background.
Since one is much larger than the other, it's overflowing on the other renderers,
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 (including padding) and opaqueBackground extents match, so that it doesn't overflow.
Need to think about it more...
Maurice
-----Message d'origine-----
De : Alex Harui [mailto:aharui@adobe.com]
Envoyé : lundi 24 février 2014 06:20
À : dev@flex.apache.org
Objet : RE: Need your help on problem with 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 included descent if there are any descenders in the glyphs for the text to be displayed. 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 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 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 bitmap for the top of the glyphs! I thought there were lineMetrics information 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=true (regular r/o labels):
1) getPreferredBoundsHeight() returns tightTextHeight (which is basically the pixel height of "T" for single line text, and top pixel to baseline of last line for multineline )
The comment says " This is the height used for positioning text according to 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 - tightTextHeight) The comment says:
// we want to return the text field height without the top and bottom offsets
// (measuredTextSize.y - tightTextHeight) gives us the sum of top and bottom 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 the top pixel to the bottom pixel of the text, majored to make sure no clipping 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é : dimanche 23 février 2014 20:37
À : 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 approximations were somehow compensated by big enough paddings.
I have seen that useTightTextBound=true is for regural text and useTightTextBound=false for editable text (TextArea, TextInput).
So I will focus on the case where useTightTextBound = true, to minimize the impact.
This will probably break some Mustella mobile tests.
Maurice
-----Message d'origine-----
De : Alex Harui [mailto:aharui@adobe.com] Envoyé : dimanche 23 février 2014 20:10 À : 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.
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 the 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=true", 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 the same value, the text will get the same height:
layoutContents()
labelDisplay. setLayoutBoundsSize ( width, 36).
But in StylableTextField. setLayoutBoundsSize(), there is some logic regarding useTightTextBounds
And at the end it set text.height = 63 !! (instead of 36).
I don't know if SFT. setLayoutBoundSize (STF.getPreferredWidth() , STF.getPreferredBoundHeight) 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 = measuredTextSize.y - tightTextTopOffset - tightTextHeight;
// when clipping, allow gutter to be outside of height
// use 2x gutter (actual gutter is not part of tight text height)
// when newHeight==1, actual visible height==3 (1px + 1x gutter)
if (newHeight < tightTextHeight)
bottomOffset = StyleableTextField.TEXT_HEIGHT_PADDING;
// re-add the top and bottom offsets. (measuredTextSize.y - tightTextHeight) gives us
// the sum of top and bottom offsets
newHeight += (tightTextTopOffset + bottomOffset);
}
}
this.height = newHeight;
Maurice
-----Message d'origine-----
De : Alex Harui [mailto:aharui@adobe.com] Envoyé : dimanche 23 février 2014 17:45 À : 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% larger? What does transform.pixelbounds show? Does it have to do with the border 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, the bottom separators between items are not displayed.
After some hours of debugging, I finally found the cause, but don't know how to fix it, because it's related to AIR.
Here is the story, in short (details in the ticket):
- Mobile item renderers "opaqueBackground=color" property draws an opaque background behind item renderers, to make scrolling faster (no transparency).
- When StyleableTextField (text used in mobile renderers, inheriting from TextField) is given WxH size in flex, its actual extent will be around 15% larger
- the opaqueBackground extent of a renderer (DisplayObject) is computed 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 size > 50, opaqueBackgorund overflows the item render size, and separator lines 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 opaqueBackground never overflows.
- etc...
What do you think ?
Maurice
RE: Need your help on problem with opaqueBackground
Posted by Alex Harui <ah...@adobe.com>.
Hmm. 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 displayed. 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 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 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 bitmap for the top of the glyphs! I thought there were lineMetrics information 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=true (regular r/o labels):
1) getPreferredBoundsHeight() returns tightTextHeight (which is basically the pixel height of "T" for single line text, and top pixel to baseline of last line for multineline )
The comment says " This is the height used for positioning text according to 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 - tightTextHeight)
The comment says:
// we want to return the text field height without the top and bottom offsets
// (measuredTextSize.y - tightTextHeight) gives us the sum of top and bottom 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 the top pixel to the bottom pixel of the text, majored to make sure no clipping 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é : dimanche 23 février 2014 20:37
À : 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 approximations were somehow compensated by big enough paddings.
I have seen that useTightTextBound=true is for regural text and useTightTextBound=false for editable text (TextArea, TextInput).
So I will focus on the case where useTightTextBound = true, to minimize the impact.
This will probably break some Mustella mobile tests.
Maurice
-----Message d'origine-----
De : Alex Harui [mailto:aharui@adobe.com] Envoyé : dimanche 23 février 2014 20:10 À : 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.
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 the 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=true", 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 the same value, the text will get the same height:
layoutContents()
labelDisplay. setLayoutBoundsSize ( width, 36).
But in StylableTextField. setLayoutBoundsSize(), there is some logic regarding useTightTextBounds
And at the end it set text.height = 63 !! (instead of 36).
I don't know if SFT. setLayoutBoundSize (STF.getPreferredWidth() , STF.getPreferredBoundHeight) 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 = measuredTextSize.y - tightTextTopOffset - tightTextHeight;
// when clipping, allow gutter to be outside of height
// use 2x gutter (actual gutter is not part of tight text height)
// when newHeight==1, actual visible height==3 (1px + 1x gutter)
if (newHeight < tightTextHeight)
bottomOffset = StyleableTextField.TEXT_HEIGHT_PADDING;
// re-add the top and bottom offsets. (measuredTextSize.y - tightTextHeight) gives us
// the sum of top and bottom offsets
newHeight += (tightTextTopOffset + bottomOffset);
}
}
this.height = newHeight;
Maurice
-----Message d'origine-----
De : Alex Harui [mailto:aharui@adobe.com] Envoyé : dimanche 23 février 2014 17:45 À : 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% larger? What does transform.pixelbounds show? Does it have to do with the border 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, the bottom separators between items are not displayed.
After some hours of debugging, I finally found the cause, but don't know how to fix it, because it's related to AIR.
Here is the story, in short (details in the ticket):
- Mobile item renderers "opaqueBackground=color" property draws an opaque background behind item renderers, to make scrolling faster (no transparency).
- When StyleableTextField (text used in mobile renderers, inheriting from TextField) is given WxH size in flex, its actual extent will be around 15% larger
- the opaqueBackground extent of a renderer (DisplayObject) is computed 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 size > 50, opaqueBackgorund overflows the item render size, and separator lines 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 opaqueBackground never overflows.
- etc...
What do you think ?
Maurice
RE: Need your help on problem with opaqueBackground
Posted by Maurice Amsellem <ma...@systar.com>.
More findings (and questions):
I am considering the case when StyleableTextField useTightTextBound=true (regular r/o labels):
1) getPreferredBoundsHeight() returns tightTextHeight (which is basically the pixel height of "T" for single line text, and top pixel to baseline of last line for multineline )
The comment says " This is the height used for positioning text according to 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 - tightTextHeight)
The comment says:
// we want to return the text field height without the top and bottom offsets
// (measuredTextSize.y - tightTextHeight) gives us the sum of top and bottom 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 the top pixel to the bottom pixel of the text, majored to make sure no clipping 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é : dimanche 23 février 2014 20:37
À : 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 approximations were somehow compensated by big enough paddings.
I have seen that useTightTextBound=true is for regural text and useTightTextBound=false for editable text (TextArea, TextInput).
So I will focus on the case where useTightTextBound = true, to minimize the impact.
This will probably break some Mustella mobile tests.
Maurice
-----Message d'origine-----
De : Alex Harui [mailto:aharui@adobe.com] Envoyé : dimanche 23 février 2014 20:10 À : 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.
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 the 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=true", 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 the same value, the text will get the same height:
layoutContents()
labelDisplay. setLayoutBoundsSize ( width, 36).
But in StylableTextField. setLayoutBoundsSize(), there is some logic regarding useTightTextBounds
And at the end it set text.height = 63 !! (instead of 36).
I don't know if SFT. setLayoutBoundSize (STF.getPreferredWidth() , STF.getPreferredBoundHeight) 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 = measuredTextSize.y - tightTextTopOffset - tightTextHeight;
// when clipping, allow gutter to be outside of height
// use 2x gutter (actual gutter is not part of tight text height)
// when newHeight==1, actual visible height==3 (1px + 1x gutter)
if (newHeight < tightTextHeight)
bottomOffset = StyleableTextField.TEXT_HEIGHT_PADDING;
// re-add the top and bottom offsets. (measuredTextSize.y - tightTextHeight) gives us
// the sum of top and bottom offsets
newHeight += (tightTextTopOffset + bottomOffset);
}
}
this.height = newHeight;
Maurice
-----Message d'origine-----
De : Alex Harui [mailto:aharui@adobe.com] Envoyé : dimanche 23 février 2014 17:45 À : 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% larger? What does transform.pixelbounds show? Does it have to do with the border 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, the bottom separators between items are not displayed.
After some hours of debugging, I finally found the cause, but don't know how to fix it, because it's related to AIR.
Here is the story, in short (details in the ticket):
- Mobile item renderers "opaqueBackground=color" property draws an opaque background behind item renderers, to make scrolling faster (no transparency).
- When StyleableTextField (text used in mobile renderers, inheriting from TextField) is given WxH size in flex, its actual extent will be around 15% larger
- the opaqueBackground extent of a renderer (DisplayObject) is computed 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 size > 50, opaqueBackgorund overflows the item render size, and separator lines 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 opaqueBackground never overflows.
- etc...
What do you think ?
Maurice
RE: Need your help on problem with opaqueBackground
Posted by Maurice Amsellem <ma...@systar.com>.
>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 approximations were somehow compensated by big enough paddings.
I have seen that useTightTextBound=true is for regural text and useTightTextBound=false for editable text (TextArea, TextInput).
So I will focus on the case where useTightTextBound = true, to minimize the impact.
This will probably break some Mustella mobile tests.
Maurice
-----Message d'origine-----
De : Alex Harui [mailto:aharui@adobe.com]
Envoyé : dimanche 23 février 2014 20:10
À : 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.
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 the 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=true", 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 the same value, the text will get the same height:
layoutContents()
labelDisplay. setLayoutBoundsSize ( width, 36).
But in StylableTextField. setLayoutBoundsSize(), there is some logic regarding useTightTextBounds
And at the end it set text.height = 63 !! (instead of 36).
I don't know if SFT. setLayoutBoundSize (STF.getPreferredWidth() , STF.getPreferredBoundHeight) 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 = measuredTextSize.y - tightTextTopOffset - tightTextHeight;
// when clipping, allow gutter to be outside of height
// use 2x gutter (actual gutter is not part of tight text height)
// when newHeight==1, actual visible height==3 (1px + 1x gutter)
if (newHeight < tightTextHeight)
bottomOffset = StyleableTextField.TEXT_HEIGHT_PADDING;
// re-add the top and bottom offsets. (measuredTextSize.y - tightTextHeight) gives us
// the sum of top and bottom offsets
newHeight += (tightTextTopOffset + bottomOffset);
}
}
this.height = newHeight;
Maurice
-----Message d'origine-----
De : Alex Harui [mailto:aharui@adobe.com] Envoyé : dimanche 23 février 2014 17:45 À : 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% larger? What does transform.pixelbounds show? Does it have to do with the border 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, the bottom separators between items are not displayed.
After some hours of debugging, I finally found the cause, but don't know how to fix it, because it's related to AIR.
Here is the story, in short (details in the ticket):
- Mobile item renderers "opaqueBackground=color" property draws an opaque background behind item renderers, to make scrolling faster (no transparency).
- When StyleableTextField (text used in mobile renderers, inheriting from TextField) is given WxH size in flex, its actual extent will be around 15% larger
- the opaqueBackground extent of a renderer (DisplayObject) is computed 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 size > 50, opaqueBackgorund overflows the item render size, and separator lines 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 opaqueBackground never overflows.
- etc...
What do you think ?
Maurice
RE: Need your help on problem with opaqueBackground
Posted by Alex Harui <ah...@adobe.com>.
I agree that the logic may need fixing. It may not have been tested at large 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 the 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=true", 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 the same value, the text will get the same height:
layoutContents()
labelDisplay. setLayoutBoundsSize ( width, 36).
But in StylableTextField. setLayoutBoundsSize(), there is some logic regarding useTightTextBounds
And at the end it set text.height = 63 !! (instead of 36).
I don't know if SFT. setLayoutBoundSize (STF.getPreferredWidth() , STF.getPreferredBoundHeight) 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 = measuredTextSize.y - tightTextTopOffset - tightTextHeight;
// when clipping, allow gutter to be outside of height
// use 2x gutter (actual gutter is not part of tight text height)
// when newHeight==1, actual visible height==3 (1px + 1x gutter)
if (newHeight < tightTextHeight)
bottomOffset = StyleableTextField.TEXT_HEIGHT_PADDING;
// re-add the top and bottom offsets. (measuredTextSize.y - tightTextHeight) gives us
// the sum of top and bottom offsets
newHeight += (tightTextTopOffset + bottomOffset);
}
}
this.height = newHeight;
Maurice
-----Message d'origine-----
De : Alex Harui [mailto:aharui@adobe.com]
Envoyé : dimanche 23 février 2014 17:45
À : 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% larger? What does transform.pixelbounds show? Does it have to do with the border 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, the bottom separators between items are not displayed.
After some hours of debugging, I finally found the cause, but don't know how to fix it, because it's related to AIR.
Here is the story, in short (details in the ticket):
- Mobile item renderers "opaqueBackground=color" property draws an opaque background behind item renderers, to make scrolling faster (no transparency).
- When StyleableTextField (text used in mobile renderers, inheriting from TextField) is given WxH size in flex, its actual extent will be around 15% larger
- the opaqueBackground extent of a renderer (DisplayObject) is computed 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 size > 50, opaqueBackgorund overflows the item render size, and separator lines 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 opaqueBackground never overflows.
- etc...
What do you think ?
Maurice
RE: Need your help on problem with opaqueBackground
Posted by Maurice Amsellem <ma...@systar.com>.
The 15% was an empirical finding based on comparing "unscaledHeight" and the 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=true", 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 the same value, the text will get the same height:
layoutContents()
labelDisplay. setLayoutBoundsSize ( width, 36).
But in StylableTextField. setLayoutBoundsSize(), there is some logic regarding useTightTextBounds
And at the end it set text.height = 63 !! (instead of 36).
I don't know if SFT. setLayoutBoundSize (STF.getPreferredWidth() , STF.getPreferredBoundHeight) 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 = measuredTextSize.y - tightTextTopOffset - tightTextHeight;
// when clipping, allow gutter to be outside of height
// use 2x gutter (actual gutter is not part of tight text height)
// when newHeight==1, actual visible height==3 (1px + 1x gutter)
if (newHeight < tightTextHeight)
bottomOffset = StyleableTextField.TEXT_HEIGHT_PADDING;
// re-add the top and bottom offsets. (measuredTextSize.y - tightTextHeight) gives us
// the sum of top and bottom offsets
newHeight += (tightTextTopOffset + bottomOffset);
}
}
this.height = newHeight;
Maurice
-----Message d'origine-----
De : Alex Harui [mailto:aharui@adobe.com]
Envoyé : dimanche 23 février 2014 17:45
À : 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% larger? What does transform.pixelbounds show? Does it have to do with the border 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, the bottom separators between items are not displayed.
After some hours of debugging, I finally found the cause, but don't know how to fix it, because it's related to AIR.
Here is the story, in short (details in the ticket):
- Mobile item renderers "opaqueBackground=color" property draws an opaque background behind item renderers, to make scrolling faster (no transparency).
- When StyleableTextField (text used in mobile renderers, inheriting from TextField) is given WxH size in flex, its actual extent will be around 15% larger
- the opaqueBackground extent of a renderer (DisplayObject) is computed 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 size > 50, opaqueBackgorund overflows the item render size, and separator lines 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 opaqueBackground never overflows.
- etc...
What do you think ?
Maurice
RE: Need your help on problem with opaqueBackground
Posted by Alex Harui <ah...@adobe.com>.
The TextField extent is surprising to me. What does it mean to be 15% larger? What does transform.pixelbounds show? Does it have to do with the border 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, the bottom separators between items are not displayed.
After some hours of debugging, I finally found the cause, but don't know how to fix it, because it's related to AIR.
Here is the story, in short (details in the ticket):
- Mobile item renderers "opaqueBackground=color" property draws an opaque background behind item renderers, to make scrolling faster (no transparency).
- When StyleableTextField (text used in mobile renderers, inheriting from TextField) is given WxH size in flex, its actual extent will be around 15% larger
- the opaqueBackground extent of a renderer (DisplayObject) is computed 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 size > 50, opaqueBackgorund overflows the item render size, and separator lines 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 opaqueBackground never overflows.
- etc...
What do you think ?
Maurice