You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@flex.apache.org by Alex Harui <ah...@adobe.com> on 2013/06/18 15:53:53 UTC
Re: git commit: [flex-sdk] [refs/heads/develop] - FLEX-24257 Fixed
measured width of date field as it may vary month by month based on format.
Hi Justin,
Thanks for looking into it. Seems like a reasonable approach, but one
concern is that adding a loop in measure may affect performance. I'm
thinking of the DataGrid with lots of DateFields in the renderers.
Imagine a file system datagrid with creation, modification and
last-accessed date columns.
Do you have time to build a static cache based on
fontSize/fontstyle/fontweight. There might be code in
EmbeddedFontRegistry you can borrow?
FWIW, another approach would be a "typicalDate" property so folks can
offer up the pattern that will reserve enough space for them, but I think
loop-and-cache is more "automatic".
-Alex
On 6/18/13 4:00 AM, "jmclean@apache.org" <jm...@apache.org> wrote:
>Updated Branches:
> refs/heads/develop 965ec7616 -> 04b8b35ca
>
>
>FLEX-24257 Fixed measured width of date field as it may vary month by
>month based on format.
>
>
>Project: http://git-wip-us.apache.org/repos/asf/flex-sdk/repo
>Commit: http://git-wip-us.apache.org/repos/asf/flex-sdk/commit/04b8b35c
>Tree: http://git-wip-us.apache.org/repos/asf/flex-sdk/tree/04b8b35c
>Diff: http://git-wip-us.apache.org/repos/asf/flex-sdk/diff/04b8b35c
>
>Branch: refs/heads/develop
>Commit: 04b8b35ca28eb74323032ce3835944e6064a8902
>Parents: 965ec76
>Author: Justin Mclean <jm...@apache.org>
>Authored: Tue Jun 18 20:58:45 2013 +1000
>Committer: Justin Mclean <jm...@apache.org>
>Committed: Tue Jun 18 20:58:45 2013 +1000
>
>----------------------------------------------------------------------
> .../projects/mx/src/mx/controls/DateField.as | 19 +++++++++++++++----
> 1 file changed, 15 insertions(+), 4 deletions(-)
>----------------------------------------------------------------------
>
>
>http://git-wip-us.apache.org/repos/asf/flex-sdk/blob/04b8b35c/frameworks/p
>rojects/mx/src/mx/controls/DateField.as
>----------------------------------------------------------------------
>diff --git a/frameworks/projects/mx/src/mx/controls/DateField.as
>b/frameworks/projects/mx/src/mx/controls/DateField.as
>index 9c65abc..e78074b 100644
>--- a/frameworks/projects/mx/src/mx/controls/DateField.as
>+++ b/frameworks/projects/mx/src/mx/controls/DateField.as
>@@ -2203,11 +2203,22 @@ public class DateField extends ComboBase
> var buttonWidth:Number =
>downArrowButton.getExplicitOrMeasuredWidth();
> var buttonHeight:Number =
>downArrowButton.getExplicitOrMeasuredHeight();
>
>- var bigDate:Date = new Date(2004, 12, 31);
>- var txt:String = (_labelFunction != null) ?
>_labelFunction(bigDate) :
>- dateToString(bigDate, formatString);
>+ var bigDate:Date;
>+ var txt:String;
>+ var textWidth:Number;
>+ var maxWidth:Number = 0;
>+
>+ // Width may vary based on date format
>+ for (var month:int = 0; month < 12; month++) {
>+ bigDate = new Date(2000, month, 28); // day 28 exist in all months
>+ txt = (_labelFunction != null) ? _labelFunction(bigDate) :
>dateToString(bigDate, formatString);
>+ textWidth = measureText(txt).width;
>+ if (textWidth > maxWidth) {
>+ maxWidth = textWidth;
>+ }
>+ }
>
>- measuredMinWidth = measuredWidth = measureText(txt).width + 8 +
>2 + buttonWidth;
>+ measuredMinWidth = measuredWidth = maxWidth + 8 + 2 +
>buttonWidth;
> measuredMinWidth = measuredWidth += getStyle("paddingLeft") +
>getStyle("paddingRight");
> measuredMinHeight = measuredHeight =
>textInput.getExplicitOrMeasuredHeight();
> }
>
Re: git commit: [flex-sdk] [refs/heads/develop] - FLEX-24257 Fixed measured width of date field as it may vary month by month based on format.
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
> Thanks for looking into it. Seems like a reasonable approach, but one
> concern is that adding a loop in measure may affect performance.
As it based on label function/format strings and font I'm not sure a cache would help that much ie different DateFields could use different date formats strings or label functions.
I'd rather check there is a performance issue before looking into with any possible optimisation.
> FWIW, another approach would be a "typicalDate" property so folks can
> offer up the pattern that will reserve enough space for them
They would need to pass the widest date not the typical one and that may be hard to know up front and would vary based on the locale.
There may also be date formats/font combinations that my method of picking the 28th of each month may pick up the widest but I'd guess they are rare and it's better than either the current method (which is always wrong for anything other than straight digits) or going though all dates in existence.
Thanks,
Justin
Re: git commit: [flex-sdk] [refs/heads/develop] - FLEX-24257 Fixed
measured width of date field as it may vary month by month based on format.
Posted by Alex Harui <ah...@adobe.com>.
On 6/18/13 7:48 AM, "Justin Mclean" <ju...@classsoftware.com> wrote:
>Hi,
>
>Re performance point of view I don't see there's an issue, measure take
>some time but it not significant.
>
>With a test of a mx datagrid with a 1000 rows and 10 columns of
>DateFields, displaying full screen and running through advanced telemetry
>and looking at the results in Scout.
>
>On startup DateField.measure takes up less than 1% of the total time
>(44ms of a total of 5,374ms), scrolling and interacting with the DG it's
>even less (25ms of 5455ms total).
>
>Methods like CreateUID, get name, get compatibilityVersion, getStyle,
>Date.getMonth or String.isWhitespace take more time than the new
>DateField.measure.
OK, thanks for double checking.
-Alex
Re: git commit: [flex-sdk] [refs/heads/develop] - FLEX-24257 Fixed measured width of date field as it may vary month by month based on format.
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
Re performance point of view I don't see there's an issue, measure take some time but it not significant.
With a test of a mx datagrid with a 1000 rows and 10 columns of DateFields, displaying full screen and running through advanced telemetry and looking at the results in Scout.
On startup DateField.measure takes up less than 1% of the total time (44ms of a total of 5,374ms), scrolling and interacting with the DG it's even less (25ms of 5455ms total).
Methods like CreateUID, get name, get compatibilityVersion, getStyle, Date.getMonth or String.isWhitespace take more time than the new DateField.measure.
Thanks,
Justin