Hi Justin,
I think you are talking about: baselines/
ActionBar_TitleDisplay_TextDecoration@android_240ppi.png, which is the only one
that turns black when crossing the descender y.
I found it weird at first sight, because StyleableStageText /
ScrollableStageText does not even have a
To be absolutely sure it was not related to TextInput, this is what I did:
In /components/ActionBar/swfs/ActionBar.mxml
I removed all the content, except:
comps:ActionBarBasic id=actionBar /
Then I did a minirun on that special test case:
./mini_run.sh -mobile
Hi,
To be absolutely sure it was not related to TextInput.
Then you need to revert the change to that single bitmap and we need to find
(and fix or revert) what checkin did cause the issue.
Thanks,
Justin
Then you need to revert the change to that single bitmap and we need to find
(and fix or revert) what checkin did cause the issue.
Before of removing all the changes I made (that's a lot of work, and I am
really running out of time), I propose to set back defaults.css to use the
original
Hi,
Before of removing all the changes I made (that's a lot of work, and I am
really running out of time),
I wasn't suggesting that just the single bitmap that was checked in in error,
so we know there's still an issue. Then we try and hunt for it's cause.
Thanks,
Justin
Justin,
I removed all my changes on my local git copy (applied revert patch), including
reverting the baseline bitmap.
Then generated the faulty test:
$ ./mini_run.sh -mobile -caseName=ActionBar_TitleDisplay_TextDecoration
tests/mobile/components/ActionBar/styles/ActionBar_Styles.mxml
As
Hi,
How is it possible to know when the test above succeeded for the last time ?
Possibly silly question but you did recompile the entire framework before
running the the tests? That's caught me out once or twice.
Maybe it was before we moved to AIR3.9/FP 11.9...
That's also a possibility.
Possibly silly question but you did recompile the entire framework before
running the the tests? That's caught me out once or twice.
Of course, how stupid I am.
I pulled all the changes from the remote develop, but didn't recompile the
framework to make them effective.
I am doing that right
Rebuilt the full SDK , and re-run the tests.
Same result...on y and underline.
So maybe AIR 3.9/FP 11.9
-Message d'origine-
De : Maurice Amsellem [mailto:maurice.amsel...@systar.com]
Envoyé : mardi 19 novembre 2013 23:36
À : dev@flex.apache.org
Objet : RE: git commit: [flex-sdk]
Hi,
Same result...on y and underline.
Or another recent check in? You can revert the check in for that image as the
change is unrelated to your fix.
Thanks,
Justin
Or another recent check in? You can revert the check in for that image as the
change is unrelated to your fix.
Sorry I don't understand, what check in should I revert?
BTW, I would like to run the same test on SDK 4.11, so I changed sdk.dir in
local.properties.
But it complains that the SDK
I understand.
The png is the same, but the DL.xml is different, as I explained in earlier
email, it contains references to ScrollableStageText (my changes) but that are
not active (width=0 height=0).
That's why I checked in both, so that they are consistent.
So I will revert both files,
Hi,
The png is the same
The png is not the same look at it before and after in that checkin. Before the
underline is entirely white, after it is black where it crosses the y.
Github has some nice way of checking for bitmap differences.
Another possibility is that the tests in the file have side-effects. Are
you running a single test or all tests in a folder? Sometimes the other
tests in a folder affect the bitmap of a single test.
-Alex
On 11/19/13 3:15 PM, Justin Mclean jus...@classsoftware.com wrote:
Hi,
Same
On 11/19/13 4:24 PM, Maurice Amsellem maurice.amsel...@systar.com
wrote:
I am not sure of that last point.
When a baseline provides both the bitmap and the xml DL, and the bitmap
is the same, but the xml DL differs,
Will the test fail, and generate .bad for both ?
If the bitmap compares exactly
If the bitmap compares exactly the display list is not compared.
Thanks
-Message d'origine-
De : Alex Harui [mailto:aha...@adobe.com]
Envoyé : mercredi 20 novembre 2013 01:43
À : dev@flex.apache.org
Objet : Re: git commit: [flex-sdk] [refs/heads/develop] - UPDATED - Tentative
FIX of
Another possibility is that the tests in the file have side-effects. Are you
running a single test or all tests in a folder? Sometimes the other tests in
a folder affect the bitmap of a single test.
I have run all the tests in mobile/ActionBar/styles, same result
-Message d'origine-
Some interesting findings:
This is what I did:
In mustella, local.properties, set
sdk.dir to point to latest SDK 4.11 GA
apollo_location=${sdk.dir}
then run again the same test.
The log says:
[echo] sdk.dir: C:/Program Files (x86)/Apache
Flex/Apache_Flex_SDK_411_GA
...
And also in SDK 4.10 GA.
So let's recap:
- running with the current SDK a standalone mobile air app that displays an
action bar with embedded font and underline = no artifact
- running current mustella test mobile/Action with current SDK = artifact is
there
- running current mustella test
Hi,
I checked all the before and after bitmaps and found one issue.
In the ActionBar_TitleDisplay_TextDecoration test, the underline on the text
Default Style is incorrect on the after bitmap as it turns black where it
crosses the descender of the y.
Thanks,
Justin
20 matches
Mail list logo
