incubator-flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Frédéric THOMAS <webdoubl...@hotmail.com>
Subject Re: About Flex runtime
Date Sat, 27 Oct 2012 17:34:11 GMT
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" <webdoublefx@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" <webdoublefx@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


Mime
View raw message