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:[email protected]]
Envoyé : dimanche 23 février 2014 17:45
À : [email protected]
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 [[email protected]]
Sent: Sunday, February 23, 2014 5:20 AM
To: [email protected]
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
