You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@flex.apache.org by Frédéric THOMAS <we...@hotmail.com> on 2012/11/05 03:51:39 UTC
Re: About Flex runtime
Hi Alex,
I didn't had time to rerun the tests in 10.3 untill now.
1- Only during this week,I noticed there is a switch in the mustella
build.xml to set the right swf-version relative to the playerglobal's one,
then there's no need to set it in the build.properties as I did.
2- As you indicated me, I had to configure an http server to make the
MarshallPlan tests pass.
3- I've still got 48 failures, that's because they expect english error text
to be return and my debug flash player version output them in french.
[java] resources/Locale/Properties/Locale_Properties_variant
Locale_variant_is_read_only Failed AssertErro(body:ste
p 2) Expected Error ReferenceError: Error #1074: Illegal write to read-only
property variant on mx.resources.Locale., g
ot ReferenceError: Error #1074: Ecriture illÚgale dans une propriÚtÚ en
lecture seule variant sur mx.resources.Locale.
How can I make that pass ? (I tried to change the os and keybord language to
US but it didn't change anything)
-----Message d'origine-----
From: Alex Harui
Sent: Monday, October 29, 2012 6:37 AM
To: flex-dev@incubator.apache.org
Subject: Re: About Flex runtime
On 10/28/12 9:55 PM, "Justin Mclean" <ju...@classsoftware.com> wrote:
> Hi,
>
>> The SDK should not need to be built for particular player versions.
>
> Currently 4.8 requires 11.1 (specified as minimum player version in
> flex-config.xml) which means as far as I'm aware you can't compile an
> application using the current SDK and make it run in flash player 11.0 or
> below. To do so you need to recompile the SDK against the version (say
> 11.0)
> you want to run it in. Am I mistaken here?
Theoretically, the abc code in each SWC is the same regardless of which
playerglobal you compile against (except for the swf-version in the
library.swf in the swc, and unless there is some 11.x specific APIs in use
somewhere, which I think you didn't find any. So, the only reason to choose
a particular playerglobal at build time is for specific player APIs that
were introduced in that version. The swf-version in the swc is ignored.
The abc code from the swc is linked into the app and the swf-version at that
compile is put in the swf and dictates everything at runtime.
And, in fact, I built the components/Label mustella SWFs using playerglobal
11.1 and then ran the SWFs on 10.3 and they all ran fine other than the
bitmap compare mismatches.
>
> Would compiling the SDK for a higher version of the flash player give you
> possible performance benefits as it also changes the swf version (also
> specified in the flex-config.xml)?
I'm pretty sure two of the reasons Flex kept forcing player upgrades was for
performance improvements and bug fixes in the player. But are any of them
"critical"? I don't really know. I personally don't want to take the time
to run all of mustella against older and new versions (at least, right now),
but I am certainly interested in the results from anyone who wants to take
that on.
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
Re: About Flex runtime
Posted by Alex Harui <ah...@adobe.com>.
On 11/6/12 5:03 PM, "Frédéric THOMAS" <we...@hotmail.com> wrote:
> misconfigured ?
>
> I can't figure out how... could you elaborate pls ?
Let's say you opt out of choosing to set up the embedded font libraries. If
you do that, then all rotated text is blank for mx controls. Once that
happens, if you then cause a bug where rotated text controls do not size
their TextField's properly, the baselines will still compare because your
"before' baselines will be blank and the "after" baselines will be blank
instead of showing that fewer characters are displayed.
>
> -----Message d'origine-----
> From: Alex Harui
> Sent: Wednesday, November 07, 2012 1:58 AM
> To: flex-dev@incubator.apache.org
> Subject: Re: About Flex runtime
>
>
>
>
>> Until all the tests pass in the actual official version of the SDK,
>> switching to another swf version shouldn't be a problem when re-generating
>> the images.
>> Do I miss something ?
> Again, if you generate your own baselines, there is a chance you are
> misconfigured and will miss something.
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
Re: About Flex runtime
Posted by Frédéric THOMAS <we...@hotmail.com>.
misconfigured ?
I can't figure out how... could you elaborate pls ?
-----Message d'origine-----
From: Alex Harui
Sent: Wednesday, November 07, 2012 1:58 AM
To: flex-dev@incubator.apache.org
Subject: Re: About Flex runtime
> Until all the tests pass in the actual official version of the SDK,
> switching to another swf version shouldn't be a problem when re-generating
> the images.
> Do I miss something ?
Again, if you generate your own baselines, there is a chance you are
misconfigured and will miss something.
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
Re: About Flex runtime
Posted by Alex Harui <ah...@adobe.com>.
> Until all the tests pass in the actual official version of the SDK,
> switching to another swf version shouldn't be a problem when re-generating
> the images.
> Do I miss something ?
Again, if you generate your own baselines, there is a chance you are
misconfigured and will miss something.
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
Re: About Flex runtime
Posted by Frédéric THOMAS <we...@hotmail.com>.
> There may also be a way to speed up the current algorithm
>From what I read before, even optimizing the pause time the gain would be no
more than 1 hour which represent no more than between 1/5 and 1/8 of the
total time which is low.
> My fear is that the next player version will break the bitmaps again and
> we'll have to go and replace all of the remaining CompareBitmaps.
We discussed that already I think, It's what I have to do when building in
swf version 12 which is not a problem until I don't change any code first,
as soon as I modify the code and want to check in, I need to make sure the
14 tests pass.
Until all the tests pass in the actual official version of the SDK,
switching to another swf version shouldn't be a problem when re-generating
the images.
Do I miss something ?
-----Message d'origine-----
From: Alex Harui
Sent: Wednesday, November 07, 2012 12:03 AM
To: flex-dev@incubator.apache.org
Subject: Re: About Flex runtime
On 11/6/12 2:48 PM, "Frédéric THOMAS" <we...@hotmail.com> wrote:
> ok, I see :)
>
> ps: Given it's slower, will it be mixed with the today pixel based
> framework
> in order to be used only when there is hassle dealing with differences in
> the rendering pipeline ?
>
I suppose we could do that. We'll see as I get farther into it. My fear is
that the next player version will break the bitmaps again and we'll have to
go and replace all of the remaining CompareBitmaps. It might be better to
just accept the fact that we need to spend extra time to do display list
comparision. There may also be a way to speed up the current algorithm.
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
Re: About Flex runtime
Posted by Alex Harui <ah...@adobe.com>.
On 11/6/12 2:48 PM, "Frédéric THOMAS" <we...@hotmail.com> wrote:
> ok, I see :)
>
> ps: Given it's slower, will it be mixed with the today pixel based framework
> in order to be used only when there is hassle dealing with differences in
> the rendering pipeline ?
>
I suppose we could do that. We'll see as I get farther into it. My fear is
that the next player version will break the bitmaps again and we'll have to
go and replace all of the remaining CompareBitmaps. It might be better to
just accept the fact that we need to spend extra time to do display list
comparision. There may also be a way to speed up the current algorithm.
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
Re: About Flex runtime
Posted by Frédéric THOMAS <we...@hotmail.com>.
ok, I see :)
ps: Given it's slower, will it be mixed with the today pixel based framework
in order to be used only when there is hassle dealing with differences in
the rendering pipeline ?
-----Message d'origine-----
From: Alex Harui
Sent: Tuesday, November 06, 2012 6:31 PM
To: flex-dev@incubator.apache.org
Subject: Re: About Flex runtime
On 11/6/12 3:54 AM, "Frédéric THOMAS" <we...@hotmail.com> wrote:
> Ok, I'll do that tonight then, I'm at work now.
>
>> My early prototype of display list compares worked fine for AIR,
> FlashPlayer 11.1 and FlashPlayer 10.3
>
> You made me curious about what you did exactly :)
Instead of saving bitmaps, you save certain properties from every
dsiplayobject in XML format. The key is which properties, which is the part
I will be tuning and testing. It runs slower than bitmaps, and the
baselines if you save uncompressed XML are bigger, but if there is less
hassle dealing with differences in the rendering pipeline, it might be worth
it.
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
Re: About Flex runtime
Posted by Alex Harui <ah...@adobe.com>.
On 11/6/12 3:54 AM, "Frédéric THOMAS" <we...@hotmail.com> wrote:
> Ok, I'll do that tonight then, I'm at work now.
>
>> My early prototype of display list compares worked fine for AIR,
> FlashPlayer 11.1 and FlashPlayer 10.3
>
> You made me curious about what you did exactly :)
Instead of saving bitmaps, you save certain properties from every
dsiplayobject in XML format. The key is which properties, which is the part
I will be tuning and testing. It runs slower than bitmaps, and the
baselines if you save uncompressed XML are bigger, but if there is less
hassle dealing with differences in the rendering pipeline, it might be worth
it.
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
RE: About Flex runtime
Posted by Frédéric THOMAS <we...@hotmail.com>.
Ok, I'll do that tonight then, I'm at work now.
> My early prototype of display list compares worked fine for AIR,
FlashPlayer 11.1 and FlashPlayer 10.3
You made me curious about what you did exactly :)
-----Original Message-----
From: Alex Harui [mailto:aharui@adobe.com]
Sent: Tuesday, November 06, 2012 8:25 AM
To: flex-dev@incubator.apache.org
Subject: Re: About Flex runtime
On 11/5/12 10:44 PM, "Frédéric THOMAS" <we...@hotmail.com> wrote:
> 1- Is it preferable to wait for the relative tests pass before open a jira
?
Open it now and put in your patch before your hard disk crashes. And leave
a note that you have more things to add later.
> 2- My plan was to create a sub task of this one:
> https://issues.apache.org/jira/browse/FLEX-33233 is it convenient ?
IMO, FLEX-33233 is about differences in bitmap rendering. I think this
issue is unrelated and can just be a new issue.
PS: My early prototype of display list compares worked fine for AIR,
FlashPlayer 11.1 and FlashPlayer 10.3. Still more work to be done there
though.
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
Re: About Flex runtime
Posted by Frédéric THOMAS <we...@hotmail.com>.
Done: https://issues.apache.org/jira/browse/FLEX-33242
-----Message d'origine-----
From: Alex Harui
Sent: Tuesday, November 06, 2012 8:24 AM
To: flex-dev@incubator.apache.org
Subject: Re: About Flex runtime
On 11/5/12 10:44 PM, "Frédéric THOMAS" <we...@hotmail.com> wrote:
> 1- Is it preferable to wait for the relative tests pass before open a jira
> ?
Open it now and put in your patch before your hard disk crashes. And leave
a note that you have more things to add later.
> 2- My plan was to create a sub task of this one:
> https://issues.apache.org/jira/browse/FLEX-33233 is it convenient ?
IMO, FLEX-33233 is about differences in bitmap rendering. I think this
issue is unrelated and can just be a new issue.
PS: My early prototype of display list compares worked fine for AIR,
FlashPlayer 11.1 and FlashPlayer 10.3. Still more work to be done there
though.
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
Re: About Flex runtime
Posted by Alex Harui <ah...@adobe.com>.
On 11/5/12 10:44 PM, "Frédéric THOMAS" <we...@hotmail.com> wrote:
> 1- Is it preferable to wait for the relative tests pass before open a jira ?
Open it now and put in your patch before your hard disk crashes. And leave
a note that you have more things to add later.
> 2- My plan was to create a sub task of this one:
> https://issues.apache.org/jira/browse/FLEX-33233 is it convenient ?
IMO, FLEX-33233 is about differences in bitmap rendering. I think this
issue is unrelated and can just be a new issue.
PS: My early prototype of display list compares worked fine for AIR,
FlashPlayer 11.1 and FlashPlayer 10.3. Still more work to be done there
though.
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
Re: About Flex runtime
Posted by Frédéric THOMAS <we...@hotmail.com>.
1- Is it preferable to wait for the relative tests pass before open a jira ?
2- My plan was to create a sub task of this one:
https://issues.apache.org/jira/browse/FLEX-33233 is it convenient ?
-----Message d'origine-----
From: Alex Harui
Sent: Tuesday, November 06, 2012 6:58 AM
To: flex-dev@incubator.apache.org
Subject: Re: About Flex runtime
On 11/5/12 5:50 PM, "Frédéric THOMAS" <we...@hotmail.com> wrote:
> Actually, I implemented the last one tonight, it took me a bit of time in
> notepad ^^ but it does the job, I still have to modify the tests themself
> and that, should take me until the end of the week end, I'll be busy this
> week.
>
> Now those are valids :
> <AssertError value="Error: Le paramètre allowedFormatChars est incorrect.
> Il
> ne doit pas contenir de chiffres." />
> <AssertError value="{['ReferenceError: Error #1074:', 'country',
> 'mx.resources.Locale']}"/>
> <AssertError value="{['ReferenceError: Error #1074:']}"/>
> <AssertError value="{[]}"/> // pass each time which make sens because it
> means contains nulls
> <AssertError value=""/> // unchanged
>
> The error message for "contains" looks like: Expected Error contains
> "ReferenceError: Error #1074:"..."country"..."mx.resources.Locale", got
> ....
> (the real error)
>
> Any thoughts ?
Sounds good. If you haven't opened a JIRA bug, please do so and add the
patch files there.
Thanks!
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
Re: About Flex runtime
Posted by Alex Harui <ah...@adobe.com>.
On 11/5/12 5:50 PM, "Frédéric THOMAS" <we...@hotmail.com> wrote:
> Actually, I implemented the last one tonight, it took me a bit of time in
> notepad ^^ but it does the job, I still have to modify the tests themself
> and that, should take me until the end of the week end, I'll be busy this
> week.
>
> Now those are valids :
> <AssertError value="Error: Le paramètre allowedFormatChars est incorrect. Il
> ne doit pas contenir de chiffres." />
> <AssertError value="{['ReferenceError: Error #1074:', 'country',
> 'mx.resources.Locale']}"/>
> <AssertError value="{['ReferenceError: Error #1074:']}"/>
> <AssertError value="{[]}"/> // pass each time which make sens because it
> means contains nulls
> <AssertError value=""/> // unchanged
>
> The error message for "contains" looks like: Expected Error contains
> "ReferenceError: Error #1074:"..."country"..."mx.resources.Locale", got ....
> (the real error)
>
> Any thoughts ?
Sounds good. If you haven't opened a JIRA bug, please do so and add the
patch files there.
Thanks!
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
Re: About Flex runtime
Posted by Frédéric THOMAS <we...@hotmail.com>.
Actually, I implemented the last one tonight, it took me a bit of time in
notepad ^^ but it does the job, I still have to modify the tests themself
and that, should take me until the end of the week end, I'll be busy this
week.
Now those are valids :
<AssertError value="Error: Le paramètre allowedFormatChars est incorrect. Il
ne doit pas contenir de chiffres." />
<AssertError value="{['ReferenceError: Error #1074:', 'country',
'mx.resources.Locale']}"/>
<AssertError value="{['ReferenceError: Error #1074:']}"/>
<AssertError value="{[]}"/> // pass each time which make sens because it
means contains nulls
<AssertError value=""/> // unchanged
The error message for "contains" looks like: Expected Error contains
"ReferenceError: Error #1074:"..."country"..."mx.resources.Locale", got ....
(the real error)
Any thoughts ?
-----Message d'origine-----
From: Alex Harui
Sent: Monday, November 05, 2012 6:29 PM
To: flex-dev@incubator.apache.org
Subject: Re: About Flex runtime
On 11/4/12 11:35 PM, "Frédéric THOMAS" <we...@hotmail.com> wrote:
> I'm for the last proposal and I was thinking about to create an other
> assertion like AssertErrorContains which would take an Array as parameter
> to
> check the error value against.
>
> Something like <AssertErrorContains value="{['ReferenceError: Error
> #1074:',
> 'variant', 'mx.resources.Locale.']}"/>
>
I think I would just add a "contains" property to AssertError, we'll
probably have to go touch each one of them anyway. I would lean against
adding a new test step.
Or maybe just change AssertError to do an indexOf instead of == and override
"value" so if it gets an array it do indexOf on the array. Hmm. I like
this one better.
> What do you think ?
>
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
Re: About Flex runtime
Posted by Alex Harui <ah...@adobe.com>.
On 11/4/12 11:35 PM, "Frédéric THOMAS" <we...@hotmail.com> wrote:
> I'm for the last proposal and I was thinking about to create an other
> assertion like AssertErrorContains which would take an Array as parameter to
> check the error value against.
>
> Something like <AssertErrorContains value="{['ReferenceError: Error #1074:',
> 'variant', 'mx.resources.Locale.']}"/>
>
I think I would just add a "contains" property to AssertError, we'll
probably have to go touch each one of them anyway. I would lean against
adding a new test step.
Or maybe just change AssertError to do an indexOf instead of == and override
"value" so if it gets an array it do indexOf on the array. Hmm. I like
this one better.
> What do you think ?
>
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
Re: About Flex runtime
Posted by Frédéric THOMAS <we...@hotmail.com>.
I'm for the last proposal and I was thinking about to create an other
assertion like AssertErrorContains which would take an Array as parameter to
check the error value against.
Something like <AssertErrorContains value="{['ReferenceError: Error #1074:',
'variant', 'mx.resources.Locale.']}"/>
What do you think ?
-----Message d'origine-----
From: Alex Harui
Sent: Monday, November 05, 2012 6:12 AM
To: flex-dev@incubator.apache.org
Subject: Re: About Flex runtime
On 11/4/12 6:51 PM, "Frédéric THOMAS" <we...@hotmail.com> wrote:
> 3- I've still got 48 failures, that's because they expect english error
> text
> to be return and my debug flash player version output them in french.
>
> [java] resources/Locale/Properties/Locale_Properties_variant
> Locale_variant_is_read_only Failed AssertErro(body:ste
> p 2) Expected Error ReferenceError: Error #1074: Illegal write to
> read-only
> property variant on mx.resources.Locale., g
> ot ReferenceError: Error #1074: Ecriture illÚgale dans une propriÚtÚ en
> lecture seule variant sur mx.resources.Locale.
>
Thanks for finding this issue. I think we should change AssertError to clip
off everything after the second ":". Then it would compare just
"ReferenceError: Error #1074:".
Another option is to create a low-level sequence of code to generate the
correct answer. I did that on some tests already. There were some tests
that would sort some french strings and different Mac OS versions reported
different ordering due to some unicode standard change. The goal of those
tests were to make sure all of the Flex sorting code would return the same
order as the player would on a simple sort of some strings in an Array so
the test sets up a low-level array, sorts it, and makes that the "correct
answer". You could do somehing similar by setting up a simple AS class with
a read-only property, try to write to it, capture the error message,
determine the pattern, convert it to be the correct answer for a read-only
property on the mx.resource.Locale class.
Yet another option is the first option but also add new properties that
require that certain non-translatable strings be in the remainder of the
error message. So, a ReferenceError of #1074 that has the strings 'variant'
and 'mx.resource.Locale' in it. That would really limit false results.
I think I like this last one best. How about you?
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
Re: About Flex runtime
Posted by Alex Harui <ah...@adobe.com>.
On 11/4/12 6:51 PM, "Frédéric THOMAS" <we...@hotmail.com> wrote:
> 3- I've still got 48 failures, that's because they expect english error text
> to be return and my debug flash player version output them in french.
>
> [java] resources/Locale/Properties/Locale_Properties_variant
> Locale_variant_is_read_only Failed AssertErro(body:ste
> p 2) Expected Error ReferenceError: Error #1074: Illegal write to read-only
> property variant on mx.resources.Locale., g
> ot ReferenceError: Error #1074: Ecriture illÚgale dans une propriÚtÚ en
> lecture seule variant sur mx.resources.Locale.
>
Thanks for finding this issue. I think we should change AssertError to clip
off everything after the second ":". Then it would compare just
"ReferenceError: Error #1074:".
Another option is to create a low-level sequence of code to generate the
correct answer. I did that on some tests already. There were some tests
that would sort some french strings and different Mac OS versions reported
different ordering due to some unicode standard change. The goal of those
tests were to make sure all of the Flex sorting code would return the same
order as the player would on a simple sort of some strings in an Array so
the test sets up a low-level array, sorts it, and makes that the "correct
answer". You could do somehing similar by setting up a simple AS class with
a read-only property, try to write to it, capture the error message,
determine the pattern, convert it to be the correct answer for a read-only
property on the mx.resource.Locale class.
Yet another option is the first option but also add new properties that
require that certain non-translatable strings be in the remainder of the
error message. So, a ReferenceError of #1074 that has the strings 'variant'
and 'mx.resource.Locale' in it. That would really limit false results.
I think I like this last one best. How about you?
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui