RE: Is Any Browser At All Supporting Flash as of today?

[after24]

 Hi yishayw,

Don't sure if it will last but at the moment Firefox *ESR* 52.3.0 still
works for us (flash player 26.0.0.131)

If you want to make a try, you can download specific version of Firefox here
:  https://ftp.mozilla.org/pub/firefox/releases/
  

Vincent.




--
Sent from: http://apache-flex-development.247.n4.nabble.com/

Re: Flash builder is stucked at 57 %

[after24]

Hi Olaf, Hi Alex,

Firefox was the culprit, I uninstalled/installed it and it works again.

Thanks for your answers.

Vincent.



--
View this message in context: 
http://apache-flex-development.247.n4.nabble.com/Flash-builder-is-stucked-at-57-tp63167p63210.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.

Re: Flash builder is stucked at 57 %

[after24]

The Run button doesn't launch the project in the browser neither.
I can't find where to point to a browser in the run configuration (I set the
browser in preferences/general/ web browser)




--
View this message in context: 
http://apache-flex-development.247.n4.nabble.com/Flash-builder-is-stucked-at-57-tp63167p63175.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.

Flash builder is stucked at 57 %

[after24]

Hello,

I am facing an issue with flash builder (only on one workspace, other
workspaces are fine) where the execution process is blocked at 57 %.

If I go directly in the bin-debug folder and launch manually the generated
"project.html" file, it works and the link to the debugger is done.

I suppose it has something to do with the project configuration but I can't
find a way to solve this issue.

Anyone has the solution ?

Thanks.

Vincent. 



--
View this message in context: 
http://apache-flex-development.247.n4.nabble.com/Flash-builder-is-stucked-at-57-tp63167.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.

Re: Flex support in IntelliJ IDEA open sourced

[after24]

Hi Alexander,

This is a very good news !



--
View this message in context: 
http://apache-flex-development.247.n4.nabble.com/Flex-support-in-IntelliJ-IDEA-open-sourced-tp49034p49035.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.

Re: Re:Re: Re:Re: Re:Re: Re:Flex Scroller optimization

[after24]

Hello Darkstone,

Thanks for those tests. It would be very interesting that other users share
the results they get on other devices, especially on iOS.

I am deeply convinced that UI smoothness is a key parameter of the user
experience and has a large impact on the perception of the quality of an
application : Google made this statement 3 years ago and responded to the
choppiness of its OS with « project butter » introduced in android Jelly
Bean. I am also profoundly convinced that the lack of smoothness of Flex
mobile (on a large majority of devices) prevents many developers from using
it and is an argument for its detractors. Feather UI is a solution, it works
perfectly well and is evolving toward something more friendly for Flex
developers with the future integration of mxml, but it’s not the swiss knife
that flex is… especially for developers who build Flex based RIA with the
need of producing a mobile version of their product.

I digress a little from the initial subject but we do not say enough how
Flex is a fantastic tool. It’s clear that HTML5 is catching up and is well
suited for a lot of things but I am not in a hurry to jump in the .js train
because it seem’s to me that the existing tools are not stable, not in the
sense of execution stability but rather in evolution stability : the joke of
« a new .js framework every day » illustrates this constant evolution state
of a technology that is not quite ready for the moment when it comes to
product large scale applications in optimal conditions. It’s easy to be
scared when you follow trends on twitter and feeling like a dinosaur because
you continue to use a technology that is less popular than others. I am not
against learning a new technology, not at all, but it must be for a good
reason and not because the hype is on a particular tool for more than 2
weeks.  My job (and I think the job of a lot of people on this list) is not
to build dev tools or master 10 langages and 30 frameworks : my job is to
build applications to address clients needs, and right now, Flex is the
perfect solution. My clients are happy and don’t care about the need of
having flash player installed on their computer. Brainless flash haters or
allegedly journalists desperate to kill something, because buzz words like
kill or dead fills the void of knowledge and objectivity in journalism 5.0,
are far less numerous than happy clients and users who don’t care about the
engine brand if the engine is powerful… and smooth.

This is the reason why I try to optimize flex mobile UI animation. The
cacheViewport experiment is not a production ready feature but it clearly
shows that there is space for improvements with the current SDK. Modern
devices are more suited to run flex mobile (Darkstone, I am very impressed
with the results on your device without using the cacheViewport
optimization) but how many years will it take before every user device can
run any flex mobile project at 60 FPS ?

Regarding this experimentation, it’s right that using this technique in the
viewport itself rather than in the scroller using the touchInteraction
events is definetely not the safer solution : I’m pretty sure that mustella
won’t be very happy with the changes I made on the Scroller code even if I
tried to make them as light as possible. But like Jude says, having an out
of the box « magic button » will be a nice feature for every Flex user. It
took me a lot of time to find the most performant blitting approach and to
integrate it to the scroller, and during this process I found out that
mobile processors are not the only ones responsible for jerky animations :
the kinetic of the spark.effects.TrowEffect is far from being perfect (I
will try to use the Greensock throwPropsPlugin to see if it’s make a
significant difference).

Darkstone,

« for old smart mobile devices, which have low performance CPUs and GPUs,
and small RAMs, your cacheViewport solution is very good for use in low
performance CPUs, but the downside is your solution requires a lot memory
consumption, which is quite expensive to bear for those old devices »

Concerning this downside, it’s true that caching the whole viewport can
consume a considerable amount of memory but it should be balanced by the
fact that low end devices usually have a low pixel density screen.
Nevertheless this technique is definitely not appropriate for cases like
lists with a very large number of rows where the contentHeight property can
reach dozen of thousands of pixels, not to mention the fact that its
initialization will take a very long time because each row will lead to the
creation of an item renderer since the layout can't be virtualized.

« it seems you don't clear your bitmap cache of the viewport, which I think
you should put it into consideration »

this is deliberate because the rasterization of the viewport is a costly
process (200-300 ms on my device for the content of the demo) and should be
done only when necessary, i.e. right before the first 

Re: Re:Re: Re:Re: Re:Flex Scroller optimization

[after24]

Hello DarkStone,

Can you access the apache flex JIRA ? If you can, I could attach the .apk of
the demo version.



--
View this message in context: 
http://apache-flex-development.247.n4.nabble.com/Flex-Scroller-optimization-tp46074p46090.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.

Re: Re:Re: Re:Flex Scroller optimization

[after24]

DarkStone,Here is a Twitter link to the screen capture : 
https://twitter.com/after24_studio/status/589389289059942400
https://twitter.com/after24_studio/status/589389289059942400  1 -Both
tests are made under gpu render mode.2 -The difference between the two
techniques is significant, on a nexus 7 : - 25/30 fps with cacheAsBitmap
- 60 fps with the blitting approch (and a frame budget around 8-10 ms)



--
View this message in context: 
http://apache-flex-development.247.n4.nabble.com/Flex-Scroller-optimization-tp46074p46084.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.

Flex Scroller optimization

[after24]

Hello,

I have been working on the scroller component to improve the framerate of
the scrolling operations with an optimization based on the blitting
technique.
In this experiment, the Scroller component has a new boolean property named
cacheViewport.

When cacheViewPort is set to true, all scrolling operations are performed
according to the following cycle :
 
1 - A bitmap copy of the viewport is made just before the next scrolling
operation (large viewports are cached in multiple tiles if necessary)

2 - When the user starts a scrolling operation, the actual viewport is
replaced by its bitmap version and the scrolling is executed by drawing the
viewport according to its verticalScrollPosition and
horizontalScrollPosition properties.

3 - At the end of the scroll operation, the bitmap viewport is replaced by
its actual version.

4 - Between each scrolling operations, when the user interacts with the
viewport content, a process mark as 'dirty' every regions of the viewport
that are likely to have changed during those interactions. Every dirty
region is redrawn before the next scrolling operation.


Pros :

- 60 FPS scrolling, even on old devices.
- Performance is no longer dependant on the viewport complexity.
- Can be used with the list component if it contains a moderate number of
rows (useVirtualLayout must be set to false though)

Cons :

- There is a slight lag (dependant on the device processor) during the
viewport rasterization and the process of redrawing every dirty regions.
- Doesn't support virtualized layouts.
- Animated elements of the viewport freezes during scrolling operations.
- Render mode must be set to renderModegpu/renderMode on the current
version.
- Depending on its dimensions, the viewport rasterization process can
consume large amounts of memory.


It works well, even on old phones. I tested it on a nexus S, a nexus 4 and a
nexus 7 (however, I didn’t made tests on ios devices).

A demo application can be downloaded on the android play market here : 
https://play.google.com/store/apps/details?id=air.fr.after24.ViewportCacheDemo
https://play.google.com/store/apps/details?id=air.fr.after24.ViewportCacheDemo
  

I opened a Jira ticket with the source code  FLEX-34821
https://issues.apache.org/jira/browse/FLEX-34821  



--
View this message in context: 
http://apache-flex-development.247.n4.nabble.com/Flex-Scroller-optimization-tp46074.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.

RE: Scroller optimization

[after24]

Hello Frédéric,

Sure, I will post an android .apk sample application with the source code. I
just want to clean up the ViewportCache class before.

Vincent. 



--
View this message in context: 
http://apache-flex-development.247.n4.nabble.com/Scroller-optimization-tp41774p41876.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.

Re: Re:Re: Re:Scroller optimization

[after24]

Hi darkstone,
*
/This issue is probably caused by Scroller and the viewport's layout. When
scrolling with finger, the Scroller will update viewport's horizontal and
vertical scroll positions (actual work is done by viewport.layout), and
might involk some other layout API of the viewport. The instance to the
viewport.layout property is responsible for updating the viewport's
scrollRect, and maintaining the layout of the viewport's direct children,
depending on the structure of the viewport's children, this might consume a
lot CPU resources./*

I'm not sure about that because when the actual viewport is replaced by it's
cached version, the _viewport property of the scroller is actualized to
point on the viewportCache. So the horizontal and vertical scroll positions
shouldn't affect the actual viewport layout during scroll operations.

This  stackoverflow
http://stackoverflow.com/questions/10037262/building-small-gui-engine-visible-vs-addchild-removechild
  
post could be an explanation of the difference in performance.

Vincent.



--
View this message in context: 
http://apache-flex-development.247.n4.nabble.com/Scroller-optimization-tp41774p41883.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.

Re: Re:Scroller optimization

[after24]

Hi DarkStone,

Thank you for your response.

*
/Instead of using the scrollRect property of the viewport, the ViewportCache
performs the scrolling of the bitmap version of the viewport using the
blitting technique which is way much faster.
What do you mean by the blitting technique? Could you explain it in
detail?/*

This technique involves a bitmap canvas on which blocks of bits are copied (
wikipedia http://en.wikipedia.org/wiki/Bit_blit  ). Here, the canvas is a
Bitmap whose dimensions are equal to the viewport ones. The actual viewport
is rasterized in a BitmapData using the draw method. The viewport is
rendered using the copyPixel method of the bitmap canvas (copyPixels is very
fast).


*
/the total number of pixels of a BitmapData cannot exceed 16,777,215 pixels,
although it's large enough, it has its limit./*

My ViewportCache has a ViewportRasterizer class which performs the
rasterization work : the rasterized version of the viewport is stored in a
vector of BitmapData objects with a maximum size of 2880 x 2880. This way,
even very larges viewports can be rasterized in multiple tiles (a Vector of
Rectangles is used to store the position and size of each tile). I made some
tests on my nexus 4 with a 480 x 28 000 pixels viewport and it works at a
steady 60 fps when cacheViewport = true


*
/I would rather create a subclass of Group named CachableGroup, define two
properties for CacheableGroup: viewport:IViewport (default property) and
viewportCache:IViewportCache, then set Scroller.viewport to CacheableGroup.
The viewport property is like the actual viewport of yours…/*

I choose to integrate the viewportCache inside the scroller component so
that the user can leverage the optimization without having to change his
code (just set a property to true). Furthermore, it's easier to know when
the throw effect is complete when the optimization is implemented inside the
scroller.

*
/and I also would rather set the viewport or the viewportCache's visible to
false than using removeElement() when you don't need one of them. Cuz if you
need to show one of them (the viewport or the viewportCache) back again, the
addElement() method will have to take some time to render it, it's much
slower than setting its visible from false to true./*

Yes, this is the problem. At first I used the visible property to hide the
actual viewport during scroll operations but this method has a significant
impact on performance. I'm not sure about the cause but the fact that the
viewport remains on the display list even if it's not visible hurts
performance. That's why I choosed to remove the viewport from the scroller
skin during scrolling, in this case, performance is optimal but then, the
time needed to add it back when the scrolling is complete can be very long.

Does the runtime renders every display objects added to the display list
even if their visible property is set to false ? is the decrease in
performance between the two approaches is due to the the scroller component
?

I will make some tests with scout to see if I can identify the difference.

If this problem can be solved, this optimization will have a huge impact on
scrolling performance (as I said before, I was able to scroll enormous views
at 60 FPS using this technique).


Vincent.



--
View this message in context: 
http://apache-flex-development.247.n4.nabble.com/Scroller-optimization-tp41774p41814.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.

Scroller optimization

[after24]

Hello,

I have worked on a way to optimize the scroller component on mobile..
It's very promising, especially for very complex views, but there is a major
drawback though.

Here is how it works :

The scroller component has a new boolean property called cacheViewport :

When this property is set to true, a bitmap version of the viewport is
captured in a ViewportCache component which inherits from
SpriteVisualElement and implements IViewport.
Instead of using the scrollRect property of the viewport, the ViewportCache
performs the scrolling of the bitmap version of the viewport using the
blitting technique which is way much faster.

When the user start to scroll, the actual viewport is removed (using
removeElement) and replaced by the ViewportCache component.
When the scroll is complete, the ViewportCache is removed (using
removeElement) and replaced by the actual viewport.
When the user interacts with the viewport content, the ViewportCache has a
system that redraws the regions that are likely to have changed during those
interactions. 
 
The weakness of this method is that the viewport must be added to the
display list after each scrolling operation : this process can be very long
(500-1000 ms) for very complex views.

The idea to solve this problem would be to add the actual viewport back only
when the user interacts with its content.

I found out a way to detect this type of interaction for example the user
clic the bitmap version of a ToggleButton on the ViewportCache, but I can
not reflect this interaction on the actual viewport i.e. the actual
ToggleButton should be toggled, when it’s added back to the display list.

Do you think it's feasible ? anyone has an idea ?



--
View this message in context: 
http://apache-flex-development.247.n4.nabble.com/Scroller-optimization-tp41774.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.

Re: Improvement of mobile scrollings

[after24]

Hi Justin,

Every device capable (for a specific scroll case) to go beyond 30 fps should
take advantage of this change.
One more time, the improvement is observable during a user dragged scroll
(application framerate must be greater than 30 fps, I set it to 60 on my
devices).

Vincent.




--
View this message in context: 
http://apache-flex-development.247.n4.nabble.com/Improvement-of-mobile-scrollings-tp41029p41180.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.

Re: Improvement of mobile scrollings

[after24]

Hi Erik,

Just added a proper patch.

Have a nice day.

Vincent.



--
View this message in context: 
http://apache-flex-development.247.n4.nabble.com/Improvement-of-mobile-scrollings-tp41029p41107.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.

Improvement of mobile scrollings

[after24]

Hi,

While trying to find the best ways to get smooth scrollings on mobile, no
matter the type of optimization (pure as3 ItemRenderers...) or settings used
(framerate, stage quality...) the result is always the same :

- The scrolling is jerky when the user touch the screen (a list for example)
and drags its content.

-There is a significative difference of scrolling smoothness depending on
whether an element is thrown or dragged by the user.

The reason is due to a constant in the Spark Scroller code :

/private static const MAX_DRAG_RATE:Number = 30;/

With this constant, no matter the framerate of the application, the refresh
frequency of the viewport content position can't exceed 30 frames per
second.

Using a monkey patch I set the value of this constant to 60 (just like the
framerate of the application) and I could observe a very net improvement of
the scrolling smoothness during drag operations.

May be this value could be changed for a higher one or the constant replaced
by a property that match dynamically the framerate of the application (at
least when the framerate exceeds 30 fps).

What do you think ?



--
View this message in context: 
http://apache-flex-development.247.n4.nabble.com/Improvement-of-mobile-scrollings-tp41029.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.

Re: Improvement of mobile scrollings

[after24]

In fact the performance improves even for values greater than the application
framerate (90 seems to be the limit on my phone).



--
View this message in context: 
http://apache-flex-development.247.n4.nabble.com/Improvement-of-mobile-scrollings-tp41029p41032.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.

Re: Improvement of mobile scrollings

[after24]

Hi David,

In fact the changes of the value doesn't affect the absolute performance of
the scrolling but it removes a very limiting factor during the drag of the
content of a scroller.

Combined with a high framerate (60 fps) and a stage quality set to low
during critical animations I managed to get near native performance on a
Nexus 4.



--
View this message in context: 
http://apache-flex-development.247.n4.nabble.com/Improvement-of-mobile-scrollings-tp41029p41034.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.

Re: Improvement of mobile scrollings

[after24]

I just added a patch that replaces the private static const MAX_DRAG_RATE by
the public static property maxDragRate with a default value of 90 (former
value of the constant was 30).


link to JIRA https://issues.apache.org/jira/browse/FLEX-34213  



--
View this message in context: 
http://apache-flex-development.247.n4.nabble.com/Improvement-of-mobile-scrollings-tp41029p41040.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.

Strange behavior with setMonth method of Date object

[after24]

Hello,

I'm facing a strange behavior with the Date object :

var myDate:Date = new Date();
myDate.setFullYear(2014);
myDate.setMonth(3);
trace(myDate);  // return Thu May 1 18:31:07 GMT+0200 2014
myDate.setMonth(3);
trace(myDate); // return Tue Apr 1 18:31:07 GMT+0200 2014

The returned month is false the first time. This behavior seems to occur
only today(Mar 31, 2014), if I change my system date, the two trace
statements returns the same date.

Is it a flash player bug (the only thing I found on the Adobe bugbase is 
https://bugbase.adobe.com/index.cfm?event=bugid=2927909
https://bugbase.adobe.com/index.cfm?event=bugid=2927909  ) or am I
missing something ? 



--
View this message in context: 
http://apache-flex-development.247.n4.nabble.com/Strange-behavior-with-setMonth-method-of-Date-object-tp36525.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.

Re: Strange behavior with setMonth method of Date object

[after24]

Sorry,

I should have post this message in the flex users list.

The problem seems to be due to the fact that the day is not set initially.
So the runtime uses the system current date (March 31). But as april has
only 30 days, when setMonth(3) is executed, the date is automatically set to 
may...

So it seems to be be a very bad idea to build a date like I did :

var myDate:Date = new Date();

myDate.setFullYear(year);
myDate.setMonth(month);
myDate.setDate(day);

Instead of :

var myDate:Date = new Date(year, month, day);






--
View this message in context: 
http://apache-flex-development.247.n4.nabble.com/Strange-behavior-with-setMonth-method-of-Date-object-tp36525p36527.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.

RE: Strange behavior with setMonth method of Date object

[after24]

Hi Maurice,

I didn't see your response before responding to myself.

Thank you :-)



--
View this message in context: 
http://apache-flex-development.247.n4.nabble.com/Strange-behavior-with-setMonth-method-of-Date-object-tp36525p36528.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.

RE: Flex on Windows 8

[after24]

Hello,

I had the opportunity to test a large flex application on a surface 2 and I
must say that I have been very surprised on how well it wor



--
View this message in context: 
http://apache-flex-development.247.n4.nabble.com/Flex-on-Windows-8-tp36321p36324.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.

Re: Anyone experimenting a huge performance problem in flex MXML/AS3 editing in IntelliJ 13?

[after24]

I had not followed your link, I see that that this bug is fixed and will be
released in version 13.0.3 next week. This is great news :-)

Good week-end to everyone on the list.





--
View this message in context: 
http://apache-flex-development.247.n4.nabble.com/Anyone-experimenting-a-huge-performance-problem-in-flex-MXML-AS3-editing-in-IntelliJ-13-tp34049p34357.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.

Re: [ANNOUNCE] Welcome Maurice as the newest PMC member

[After24]

Congratulation Maurice ! this is well deserved.

Vincent.

Re: fdb

[After24]

Hi,

This is not a Flash Builder issue, it's related to your browser 
configuration.


See : 
http://stackoverflow.com/questions/7478465/flash-builder-4-5-debugger-terminates-safari


Vincent.


Le 18/04/13 15:54, Harbs a écrit :

FWIW, I've had problems in Flash Builder with Flash Debugger crashing if I 
spend too much time stepping. I was hoping IntelliJ IDEA would help with that. 
lol…

On Apr 18, 2013, at 4:29 PM, Scott Talsma wrote:


I have had issues w/Safari and Firefox sometimes dropping the connection to
the debugger if I spend too much time stepping, but that is minor.

Re: Air 3.7 in Apache Flex

[After24]

Added my vote.

Le 22/03/13 10:24, Markus Gritsch a écrit :

me too,

I don`t understand why they have to break compatibility in the first place? Does 
this mean an application developed with AIR 3.6 SDK can not run on an updated AIR 
Runtime 3.6 - to 3.7 ???

Regards,

Markus


On Mar 22, 2013, at 10:17 AM, Cosma Colanicchia wrote:


Added vote and forum comment too.


2013/3/22 Peter HO piter...@gmail.com


Hi

I added my vote too

Regards,

Peter

On 22 March 2013 09:44, Sugan Naicker su...@dev-x.co.za wrote:


Hi,

Agree. I have added my vote. There are only 12 votes currently.

Regards,

Sugan

-Original Message-
From: Roland Zwaga [mailto:rol...@stackandheap.com]
Sent: 22 March 2013 09:49 AM
To: dev@flex.apache.org
Subject: Re: Air 3.7 in Apache Flex

Just voted, I suggest everyone on this list does so as well.
Perhaps 1000 votes will sway Adobe...

On 22 March 2013 03:39, FRANKLIN GARZON fgarzo...@hotmail.com wrote:


Thanks, +1.


Franklin Garzón

Regional Development Manager

MCITP  Microsoft SQLServer


*Si el hombre dejara de aprender entonces dejaría de existir*

094496862




From: jus...@classsoftware.com
Subject: Air 3.7 in Apache Flex
Date: Fri, 22 Mar 2013 13:07:07 +1100
To: dev@flex.apache.org

HI,

Got a response back from Adobe was basically look at the AIR roadmap

(which contains noting about Apache Flex) and to raise a bug (which I
had already done so). If anyone wants to add something to be bug or
the forum post please do so. I (and I assume most other Flex
developers) would like to see Apache Flex being able to use AIR 3.7

cleanly.

http://forums.adobe.com/message/5168823#5168823

https://bugbase.adobe.com/index.cfm?event=bugid=3526506

Thanks,
Justin





--
regards,
Roland

--
Roland Zwaga
Senior Consultant | Stack  Heap BVBA

+32 (0)486 16 12 62 | rol...@stackandheap.com |
+http://www.stackandheap.com

http://zwaga.blogspot.com
http://www.springactionscript.org
http://www.as3commons.org