Mailing-List: contact flex-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: flex-dev@incubator.apache.org
Received-SPF: pass (athena.apache.org: domain of webdoublefx@hotmail.com
 designates 65.55.111.83 as permitted sender)
Message-ID: <BLU162-ds13DE73D510E84351A26D9DB47C0@phx.gbl>
From: =?iso-8859-1?Q?Fr=E9d=E9ric_THOMAS?= <webdoublefx@hotmail.com>
To: <flex-dev@incubator.apache.org>
References: <CCB2007A.47BF9%aharui@adobe.com>
In-Reply-To: <CCB2007A.47BF9%aharui@adobe.com>
Subject: Re: About Flex runtime
Date: Sun, 28 Oct 2012 08:07:40 +0100
MIME-Version: 1.0
Content-Type: text/plain;
	format=flowed;
	charset="iso-8859-1";
	reply-type=original
Content-Transfer-Encoding: 8bit
Importance: Normal

> So changing swf.version and running with -createImages doesn't really tell
you anything

All my assumption was based on what you told me before:

"The SWF version is probably the most
important thing.  If you set it to a lower number, that probably puts the
font rendering on a different code path and that will show up regardless of
Flash Player version.", which I understand as the font rendering is 
dependent
of the swf version, so, if I render a font in a particular swf version 
without
changing the code and take a snapshot (using createImages), this last can
be used a baseline image for this particular swf version, once done,
I can change the code, take another snapshot and compare them.

-----Message d'origine----- 
From: Alex Harui
Sent: Sunday, October 28, 2012 5:19 AM
To: flex-dev@incubator.apache.org
Subject: Re: About Flex runtime

I think there is confusion about what -createImages does.  It creates new
baselines based on whatever the code and player on your computer generates
and says it passes if it can successfully create the bitmap.  That option
should only be used to create a reference image, and nobody else running
that test should use that option unless they have a good reason to change
the reference images.

So changing swf.version and running with -createImages doesn't really tell
you anything.  If you accidentally made every text invisible, -createImages
would not catch that, it would just generate new reference images without
any text in them.

Therefore, we need to decide what we want to use as the reference, and set
up the scripts so that they have generate the same image on everyone's
system without extra configuration on their part.

This was easy when Flex only certified against one version of the player.  I
thought it would be relatively easy when we opened up to many player
versions, but I wasn't aware that the player changed antialiasing in FP11.
That will make things harder.


On 10/27/12 1:26 PM, "Fr�d�ric THOMAS" <webdoublefx@hotmail.com> wrote:

> Well, from what I can see, the update of the build.properties like that
> solve the problem:
>
> #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 a particular playerglobal and swf-version 
> and
> running the tests like that :
> sh mini_run.sh -all -createImages
>
> It builds the Mustella test swfs with the related playerglobal and
> swf-version and valid images (I can guess that from the fact that if I 
> build
> them against the 11.1 / 14, that creates identical images than the one 
> we've
> got under svn and gives different images compiling against an other
> playerglobal and swf-version where only the edges of the glyphs change), 
> so
> for me that solves the problem, anyone can then builds a fresh checkouted
> version of the sdk with a particular playerglobal and swf-version, 
> generates
> the images before he modifies the framework and then run the normal 
> Mustella
> tests without regenerate the images.
>
> Please tell me if I missed something ?
>
> -----Message d'origine-----
> From: Fr�d�ric THOMAS
> Sent: Saturday, October 27, 2012 8:32 PM
> To: flex-dev@incubator.apache.org
> Subject: Re: About Flex runtime
>
> Alex,
>
> Could you please enlighten me, I'm a bit confuse now, looking at the build
> of the Mustella tests, I found it uses the flex-config.xml wherein  I
> defined the playerglobal and swf version thru the build.properties, so, 
> the
> mustella tests are also compile with those arguments or I'm wrong ?
>
> -----Message d'origine-----
> From: Fr�d�ric THOMAS
> Sent: Saturday, October 27, 2012 7:34 PM
> To: flex-dev@incubator.apache.org
> Subject: Re: About Flex runtime
>
> 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