Ok, I've got it.
I thought building the framework with the good swf-version was enough :$

So, I'm gonna wait for your thoughts doing some experiments thru time.

-----Message d'origine----- From: Alex Harui
Sent: Saturday, October 27, 2012 6:58 PM
To: flex-dev@incubator.apache.org
Subject: Re: About Flex runtime

I don't understand how your change to build.properties helps.

Running -createImages creates new baselines, so you would expect all tests
to pass.  But if you check those in, then it will fail for other
swf-versions.  I think the swf-version needs to be set at the SWF level in
the .compile file.

But before we go off and do this, I want to ponder the implications, such
as, then we'd be running fewer SWFs in the newer swf-versions, and we could
miss something important.


On 10/27/12 9:29 AM, "Frédéric THOMAS" <webdoubl...@hotmail.com> wrote:

If we can be sure that the swf-version drives how flash player draws fonts,
the correction is done.

Do you want me to attach a patch to the issue ?

-----Message d'origine-----
From: Frédéric THOMAS
Sent: Saturday, October 27, 2012 6:13 PM
To: flex-dev@incubator.apache.org
Subject: Re: About Flex runtime

I updated the build.properties like that :

#10.3
swf.version = 12
#11.0
#swf.version = 13
#11.1
#swf.version = 14
#11.3
#swf.version = 15
#11.4
#swf.version = 16

building the framework against 10.3 and running the tests like that : sh
mini_run.sh tests/components/Label -createImages

The result was :


     [java] =====================================================
     [java]     Failed:
     [java] =====================================================
     [java]
     [java]
     [java] =====================================================
     [java]     Passes: 255
     [java]     Fails: 0
     [java] =====================================================
     [java]
     [java]
     [java] Wrote summary to results.txt
     [java] Wrote failures to failures.txt

call_runners:

run:

BUILD SUCCESSFUL
Total time: 1 minute 24 seconds

-----Message d'origine-----
From: Frédéric THOMAS
Sent: Saturday, October 27, 2012 5:09 PM
To: flex-dev@incubator.apache.org
Subject: Re: About Flex runtime

We could try changing the swf version on every test that doesn't require
it
to a lower number and re-create all the baseline images.

is the createImages option enough to build the baseline images?

Explictly setting swf version might be the easiest to implement, and will
help expose where the SDK has dependencies on higher swf versions (if
anywhere).

Sounds good.
swf-version from flex-config.xml could be replace by a variable set in
build.properties


-----Message d'origine-----
From: Alex Harui
Sent: Saturday, October 27, 2012 4:51 PM
To: flex-dev@incubator.apache.org
Subject: Re: About Flex runtime




On 10/27/12 5:02 AM, "Frédéric THOMAS" <webdoubl...@hotmail.com> wrote:

Back on 10.3, I did some adjustments: setting
DEFAULT_NUM_COLOR_VARIANCES:int = 255 and the default value of
ignoreMaxColorVariance to true in the CompareBitmap class, I've been able
to
reduce the number of failed tests to 1 (only
text_long_property_Label_Spark.png doesn't pass and I can't get why
because
whatever the number of color variance I allowed, it always said they
exeeded
by 4).

Well, anyway, it's not a solution, that's only to hide the failures, if we
go anyway that way, what I'm not sure, we'll need to have a conditional
compilation to say we're in a lower version of the player and the tests
should be more tolerants.

Using ignoreMaxColorVariance is not a valid option as you say.

We could see if we can set maxColorVariances to a small number like 10.
Then the odds of missing a mistake is much lower.

We could try changing the swf version on every test that doesn't require it
to a lower number and re-create all the baseline images.

We could try to install a new system that compares certain display list
properties instead of the actual bitmap output. I've argued for years that
we should do that since really, that's all our code can control.  What the
player does with the display list properties at render time is not in our
control.  But it is sensitive to different kinds of changes in our code,
like changing the z-order of two things that do not overlap or have
transparency.

Explictly setting swf version might be the easiest to implement, and will
help expose where the SDK has dependencies on higher swf versions (if
anywhere).

--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui

Reply via email to