flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Maurice Amsellem <maurice.amsel...@systar.com>
Subject RE: Need your help on problem with opaqueBackground
Date Mon, 24 Feb 2014 09:56:32 GMT
>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


Mime
View raw message