Hi Alex,
thanks for that pointer. I guess SwfxPrinter seems to be exactly what I was
looking for ... will give this a spin the next time I can free some time for
Flexmojos :-)
Chris
Von: Alex Harui [aha...@adobe.com]
Gesendet: Montag, 18. November
On Sun, Nov 17, 2013 at 11:56 PM, Maurice Amsellem
maurice.amsel...@systar.com wrote:
Checked the .bad.png.
All are the same: sub-pixel shift when the action bar contains a text
input.
This is because the text input now displays a bitmap instead of the
StageText.
Although they have the
Updated the mustella baselines for mobile/components/ActionBar failing tests.
Note: the bitmaps only differ by a few pixels, and the xml DL files have the
same coordinates and excent but bitmap instead of stageText, something like:
spark.skins.mobile.StageTextInputSkin width=200 height=53
I can try to ask the engineer who worked on it to see if he remembers
Hi Alex,
Do you think you will be able to reach the above mentioned engineer in the
coming days, to know why StyleableStageText was implemented that way ?
Maurice
-Message d'origine-
De : Alex Harui
Memory profiling of the new skins:
It's as expected: alloc memory = pixel width x pixel height x 4bytes per
pixel.
First figure is for iPad , second is for iPad retina.
- 25KB / 100 KB of bitmap memory allocated for a single line TI with default
size
- ~500KB / ~ 2 MB for a pages stuffed
Sorry, I haven't had time to follow the details. The baselines should not
be removed if they are correct for StageTextInputSkin. We may need
additional tests for the new skin classes. If you want to rename tests,
and reorganize as well, that's fine, but my understanding is that the code
paths
Sorry, I haven't had time to follow the details. The baselines should not be
removed if they are correct for StageTextInputSkin. We may need additional
tests for the new skin classes. If you want to rename tests, and reorganize
as well, that's fine, but my understanding is that the code paths
the code paths these tests used to verify are still there
Sorry, I send the email too quick.
In fact, the only visual differences between old and new baselines are because
of sub-pixel diff. The rendering is the same. And the scrolling behavior (that
is the only changed behavior) is not
Analyzing the failure.
Maurice
-Message d'origine-
De : flex.muste...@gmail.com [mailto:flex.muste...@gmail.com]
Envoyé : lundi 18 novembre 2013 17:39
À : comm...@flex.apache.org; e...@ixsoftware.nl; jmcl...@apache.org; Maurice
Amsellem
Objet : Build failed in Jenkins:
On 11/18/13 8:25 AM, Maurice Amsellem maurice.amsel...@systar.com
wrote:
the code paths these tests used to verify are still there
Sorry, I send the email too quick.
In fact, the only visual differences between old and new baselines are
because of sub-pixel diff. The rendering is the same.
I haven't seen the image diffs, so I don't know what you mean by sub-pixel.
There are two common cases: 1) a few pixels are different in corners and edges
because the anti-aliasing chose slightly different values,
You are correct, I have seen the diffs as well and there are a few different
Sorry again...I understood that you have seen the diffs and found the two use
cases.
Actually, I have only seen the first case : a few gray pixels to the edge of
the TI round rect border.
Maurice
-Message d'origine-
De : Maurice Amsellem [mailto:maurice.amsel...@systar.com]
Envoyé
On 11/18/13 9:38 AM, Maurice Amsellem maurice.amsel...@systar.com
wrote:
Anyway, I checked the xml DL, and the coordinates/extents are exactly the
same, expect that the new skin has a bitmap, so there is no computation
error and nothing we can really do about that, apart from updating the
Thank you for the information
-Message d'origine-
De : Alex Harui [mailto:aha...@adobe.com]
Envoyé : lundi 18 novembre 2013 18:58
À : dev@flex.apache.org
Objet : Re: Air Stage Text Issue
I asked him today. He pretty much confirmed what I said. The AIR team was in
the process of
On 11/18/13 11:19 AM, Maurice Amsellem maurice.amsel...@systar.com
wrote:
So does the old StyleableStageText really have less memory requirement
even in that case? Not so sure...
I don't know the code that well, but my understanding is that, if you
don't have popups, you can save on memory.
I just posted a new FlexJSOverlay.zip at FlexJSOverlay.zip at [1].
It contains most recent dependency management and strict output
corrections from Erik, and also contains better FB integration. You will
need to remove your old FlexJS launch configurations and import new ones
to get the benefit
On 11/18/13 12:19 PM, Erik de Bruin e...@ixsoftware.nl wrote:
I'm clear. Sounds awesome! Let me know when the ant script is done,
I'll work it into a Jenkins job so we get a fresh overlay for each
commit to either Falcon(Jx) or FlexJS. Another advantage, besides
being always up to date, is that
Hi,
I'm building the ListsTests using the latest FalconJX and flexjs repository
pull.
I had to make a fix to org.apache.flex.html.staticControls.Image but once that
was completed (and now pushed) I get the following two errors when I run
ListsTests in the browser:
Error: Undefined nameToPath
By the way, did you see my commit for the defaults for the command
line arguments to FalconJx? Having those should make the launch files
a bit lighter, not having to set these arguments and all.
No, I missed that. How does it work? FalconJX is also picking up the
-library-path and main mxml
On 11/18/13 1:33 PM, Erik de Bruin e...@ixsoftware.nl wrote:
By the way, did you see my commit for the defaults for the command
line arguments to FalconJx? Having those should make the launch files
a bit lighter, not having to set these arguments and all.
No, I missed that. How does it work?
Yeah, my bad. I was so focussed on getting the release code to work
that I forgot to check the debug code. Fixed now.
EdB
On Mon, Nov 18, 2013 at 9:30 PM, Peter Ent p...@adobe.com wrote:
Hi,
I'm building the ListsTests using the latest FalconJX and flexjs repository
pull.
I had to make
They are actually overrides of the defaults set in the Configuration
class and it's super classes. Nothing special, nothing dynamic ;-)
OK, I'll have to look into it. I'm specifically interested in how the
-js-lib entries get set.
'sdk-js-lib' is handled in JSGoogConfiguration.
EdB
--
Ix
Just received results of Om testing on Android (Tested on Samsung Galaxy SIII
(Android 4.1.2) and Samsung Galaxy Tab 2 (Android 4.2.2)).
It's working fine.
Thanks you Om for the quick testing, that's really good news.
Maurice
-Message d'origine-
De : Maurice Amsellem
FYI, I am still struggling with the last Mutella failure:
mobile/SoftKeyboard/properties/SK_StageText_Properties
SoftKeyboard_StageText_property_resizeForSoftKeyboard_false:
Failed DispatchMouseEvent(body:step 10) Timeout waiting for
softKeyboardActivate from navigator.activeView.notes
It's
Got it:
In Mustella FakeSoftKeyboard.as , line #71:
if (!(comp.needsSoftKeyboard ||
getQualifiedClassName(comp).indexOf(StyleableStageText) 0))
return;
:-(
Maurice
-Message d'origine-
De : Maurice Amsellem [mailto:maurice.amsel...@systar.com]
Envoyé : mardi 19 novembre
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
I was (am) a little confused about the version numbering of the new FP
(I assumed 12, Justin indicated it might be 12.0), so our beams
crossed and we ended up with a combination of the possible values.
That didn't work out well ;-)
I've change 'my' part to 12.0 and now at least the builds are
27 matches
Mail list logo
