Flex performance

classic Classic list List threaded Threaded
21 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Flex performance

Fréderic Cox
I've worked on Flex applications for the past 4-5 years and see a lot of developers picking it up since it is easy to create rich applications. However performance is often an issue.

I mostly see it when using a lot of styles (or one large CSS file) and skinned components (It is even worse with Flex 4 then it was with Flex 3). When a Flex application gets really large the UI is blocked because there is too much actionscript code needed to get things running. (with this I mean the processing time is acceptable but UI is blocked so the perception is that things are slow)

Therefore I'd like to vote on improving the performance of the Flex framework where possible so new and existing applications can benefit. Flex 4 with spark is great but comes with some performance drawbacks, I hope we can improve on this significantly.

I'm speaking on behalf of the experience and perception in the company I work for, I'm curious to see if this is also a problem for the rest of you.

I'm not the expert here but I'd like to get involved and learn so I can eventually help to fix issues but I believe UIComponent had some overhead and this together with the StyleManager can cause performance drawbacks in large applications
Reply | Threaded
Open this post in threaded view
|

Re: Flex performance

Arthur Lockman
+1 on this. Performance definitely needs to be addressed on Flex. I've noticed that on newer devices, it works fine. But on the slightly older ones, performance is a huge issue. Hopefully we can get in there and clean it up so it performs better.  


--
Arthur Lockman | Senior Developer @ Vivace
vi.vace.me
Twitter: @arthurlockman
a.rthr.me


On Wednesday, January 4, 2012 at 4:28 PM, Fréderic Cox wrote:

> I've worked on Flex applications for the past 4-5 years and see a lot of developers picking it up since it is easy to create rich applications. However performance is often an issue.
>  
> I mostly see it when using a lot of styles (or one large CSS file) and skinned components (It is even worse with Flex 4 then it was with Flex 3). When a Flex application gets really large the UI is blocked because there is too much actionscript code needed to get things running. (with this I mean the processing time is acceptable but UI is blocked so the perception is that things are slow)
>  
> Therefore I'd like to vote on improving the performance of the Flex framework where possible so new and existing applications can benefit. Flex 4 with spark is great but comes with some performance drawbacks, I hope we can improve on this significantly.
>  
> I'm speaking on behalf of the experience and perception in the company I work for, I'm curious to see if this is also a problem for the rest of you.
>  
> I'm not the expert here but I'd like to get involved and learn so I can eventually help to fix issues but I believe UIComponent had some overhead and this together with the StyleManager can cause performance drawbacks in large applications  

Reply | Threaded
Open this post in threaded view
|

Re: Flex performance

Fréderic Cox
And it's not only on mobile, on desktop (mostly Mac's) this is a problem
also. I'm talking about big enterprise applications and websites here
(like a CMS with graphical skin applied, nothing really in standard Flex
skin)

On 04/01/12 22:49, "Arthur Lockman" <[hidden email]> wrote:

>+1 on this. Performance definitely needs to be addressed on Flex. I've
>noticed that on newer devices, it works fine. But on the slightly older
>ones, performance is a huge issue. Hopefully we can get in there and
>clean it up so it performs better.
>
>
>--
>Arthur Lockman | Senior Developer @ Vivace
>vi.vace.me
>Twitter: @arthurlockman
>a.rthr.me
>
>
>On Wednesday, January 4, 2012 at 4:28 PM, Fréderic Cox wrote:
>
>> I've worked on Flex applications for the past 4-5 years and see a lot
>>of developers picking it up since it is easy to create rich
>>applications. However performance is often an issue.
>>  
>> I mostly see it when using a lot of styles (or one large CSS file) and
>>skinned components (It is even worse with Flex 4 then it was with Flex
>>3). When a Flex application gets really large the UI is blocked because
>>there is too much actionscript code needed to get things running. (with
>>this I mean the processing time is acceptable but UI is blocked so the
>>perception is that things are slow)
>>  
>> Therefore I'd like to vote on improving the performance of the Flex
>>framework where possible so new and existing applications can benefit.
>>Flex 4 with spark is great but comes with some performance drawbacks, I
>>hope we can improve on this significantly.
>>  
>> I'm speaking on behalf of the experience and perception in the company
>>I work for, I'm curious to see if this is also a problem for the rest of
>>you.
>>  
>> I'm not the expert here but I'd like to get involved and learn so I can
>>eventually help to fix issues but I believe UIComponent had some
>>overhead and this together with the StyleManager can cause performance
>>drawbacks in large applications
>


Reply | Threaded
Open this post in threaded view
|

Re: Flex performance

Arthur Lockman
Oh, I get it. I haven't worked much with those. But this does apply to the mobile scene as well. Even apps like Photoshop Touch lag quite a lot on the Galaxy tab 10.1, which came out this year. It's not a code issue, it's a framework issue. It does apply to skinning a lot as well. Just performance as a whole needs to be worked on.


--
Arthur Lockman | Senior Developer @ Vivace
vi.vace.me
Twitter: @arthurlockman
a.rthr.me


On Wednesday, January 4, 2012 at 4:56 PM, Fréderic Cox wrote:

> And it's not only on mobile, on desktop (mostly Mac's) this is a problem
> also. I'm talking about big enterprise applications and websites here
> (like a CMS with graphical skin applied, nothing really in standard Flex
> skin)
>  
> On 04/01/12 22:49, "Arthur Lockman" <[hidden email] (mailto:[hidden email])> wrote:
>  
> > +1 on this. Performance definitely needs to be addressed on Flex. I've
> > noticed that on newer devices, it works fine. But on the slightly older
> > ones, performance is a huge issue. Hopefully we can get in there and
> > clean it up so it performs better.
> >  
> >  
> > --
> > Arthur Lockman | Senior Developer @ Vivace
> > vi.vace.me (http://vi.vace.me)
> > Twitter: @arthurlockman
> > a.rthr.me (http://a.rthr.me)
> >  
> >  
> > On Wednesday, January 4, 2012 at 4:28 PM, Fréderic Cox wrote:
> >  
> > > I've worked on Flex applications for the past 4-5 years and see a lot
> > > of developers picking it up since it is easy to create rich
> > > applications. However performance is often an issue.
> > >  
> > > I mostly see it when using a lot of styles (or one large CSS file) and
> > > skinned components (It is even worse with Flex 4 then it was with Flex
> > > 3). When a Flex application gets really large the UI is blocked because
> > > there is too much actionscript code needed to get things running. (with
> > > this I mean the processing time is acceptable but UI is blocked so the
> > > perception is that things are slow)
> > >  
> > > Therefore I'd like to vote on improving the performance of the Flex
> > > framework where possible so new and existing applications can benefit.
> > > Flex 4 with spark is great but comes with some performance drawbacks, I
> > > hope we can improve on this significantly.
> > >  
> > > I'm speaking on behalf of the experience and perception in the company
> > > I work for, I'm curious to see if this is also a problem for the rest of
> > > you.
> > >  
> > > I'm not the expert here but I'd like to get involved and learn so I can
> > > eventually help to fix issues but I believe UIComponent had some
> > > overhead and this together with the StyleManager can cause performance
> > > drawbacks in large applications
> > >  
> >  
> >  
>  
>  
>  


Reply | Threaded
Open this post in threaded view
|

Re: Flex performance

Jeffry Houser
In reply to this post by Arthur Lockman

  I agree with the sentiment, but I don't think that "performance" is an
actionable item.  The Flex Framework is a big beast; what exactly do you
want to improve performance of?

  If you were to say that "I want views in a mobile web app to change
quicker when using a viewChange effect" that would be something specific
someone could look into.

  Or you could say "I want improved performance when using binding
inside an in-line itemRenderer"

  I have solved a lot of "memory/performance" issues for Flextras
clients over the years strictly by re-writing their itemRenderers to not
use bindings, but to instead respond to the dataChange event.

On 1/4/2012 4:49 PM, Arthur Lockman wrote:

> +1 on this. Performance definitely needs to be addressed on Flex. I've noticed that on newer devices, it works fine. But on the slightly older ones, performance is a huge issue. Hopefully we can get in there and clean it up so it performs better.
>
>
> --
> Arthur Lockman | Senior Developer @ Vivace
> vi.vace.me
> Twitter: @arthurlockman
> a.rthr.me
>
>
> On Wednesday, January 4, 2012 at 4:28 PM, Fréderic Cox wrote:
>
>> I've worked on Flex applications for the past 4-5 years and see a lot of developers picking it up since it is easy to create rich applications. However performance is often an issue.
>>
>> I mostly see it when using a lot of styles (or one large CSS file) and skinned components (It is even worse with Flex 4 then it was with Flex 3). When a Flex application gets really large the UI is blocked because there is too much actionscript code needed to get things running. (with this I mean the processing time is acceptable but UI is blocked so the perception is that things are slow)
>>
>> Therefore I'd like to vote on improving the performance of the Flex framework where possible so new and existing applications can benefit. Flex 4 with spark is great but comes with some performance drawbacks, I hope we can improve on this significantly.
>>
>> I'm speaking on behalf of the experience and perception in the company I work for, I'm curious to see if this is also a problem for the rest of you.
>>
>> I'm not the expert here but I'd like to get involved and learn so I can eventually help to fix issues but I believe UIComponent had some overhead and this together with the StyleManager can cause performance drawbacks in large applications
>


--
Jeffry Houser
Technical Entrepreneur
203-379-0773
--
http://www.flextras.com?c=104
UI Flex Components: Tested! Supported! Ready!
--
http://www.theflexshow.com
http://www.jeffryhouser.com
http://www.asktheflexpert.com
--
Part of the DotComIt Brain Trust


Reply | Threaded
Open this post in threaded view
|

Re: Flex performance

Fréderic Cox
There will be numerous smaller things to tackle of course, I just wanted
this general topic started to get some feedback.

- I want UIComponent to be more lightweight
- I want to reduce the performance cost of using styles and style
selectors/descendants
- I don't want UI to get blocked because of actionscript execution but use
workers or threading baked inside of the framework

Those are more specific cases like you mention where we can focus on

I avoid binding as much as I can because of the performance overhead, but
in a lot of samples it was used because it is 'fast to develop with' to
get people excited about Flex though it should be avoided if possible in
larger projects

On 04/01/12 22:56, "Jeffry Houser" <[hidden email]> wrote:

>
>  I agree with the sentiment, but I don't think that "performance" is an
>actionable item.  The Flex Framework is a big beast; what exactly do you
>want to improve performance of?
>
>  If you were to say that "I want views in a mobile web app to change
>quicker when using a viewChange effect" that would be something specific
>someone could look into.
>
>  Or you could say "I want improved performance when using binding
>inside an in-line itemRenderer"
>
>  I have solved a lot of "memory/performance" issues for Flextras
>clients over the years strictly by re-writing their itemRenderers to not
>use bindings, but to instead respond to the dataChange event.
>
>On 1/4/2012 4:49 PM, Arthur Lockman wrote:
>> +1 on this. Performance definitely needs to be addressed on Flex. I've
>>noticed that on newer devices, it works fine. But on the slightly older
>>ones, performance is a huge issue. Hopefully we can get in there and
>>clean it up so it performs better.
>>
>>
>> --
>> Arthur Lockman | Senior Developer @ Vivace
>> vi.vace.me
>> Twitter: @arthurlockman
>> a.rthr.me
>>
>>
>> On Wednesday, January 4, 2012 at 4:28 PM, Fréderic Cox wrote:
>>
>>> I've worked on Flex applications for the past 4-5 years and see a lot
>>>of developers picking it up since it is easy to create rich
>>>applications. However performance is often an issue.
>>>
>>> I mostly see it when using a lot of styles (or one large CSS file) and
>>>skinned components (It is even worse with Flex 4 then it was with Flex
>>>3). When a Flex application gets really large the UI is blocked because
>>>there is too much actionscript code needed to get things running. (with
>>>this I mean the processing time is acceptable but UI is blocked so the
>>>perception is that things are slow)
>>>
>>> Therefore I'd like to vote on improving the performance of the Flex
>>>framework where possible so new and existing applications can benefit.
>>>Flex 4 with spark is great but comes with some performance drawbacks, I
>>>hope we can improve on this significantly.
>>>
>>> I'm speaking on behalf of the experience and perception in the company
>>>I work for, I'm curious to see if this is also a problem for the rest
>>>of you.
>>>
>>> I'm not the expert here but I'd like to get involved and learn so I
>>>can eventually help to fix issues but I believe UIComponent had some
>>>overhead and this together with the StyleManager can cause performance
>>>drawbacks in large applications
>>
>
>
>--
>Jeffry Houser
>Technical Entrepreneur
>203-379-0773
>--
>http://www.flextras.com?c=104
>UI Flex Components: Tested! Supported! Ready!
>--
>http://www.theflexshow.com
>http://www.jeffryhouser.com
>http://www.asktheflexpert.com
>--
>Part of the DotComIt Brain Trust
>


Reply | Threaded
Open this post in threaded view
|

Re: Flex performance

Raju Bitter
In reply to this post by Fréderic Cox
It would make sense to build a light-weight component set for Flex,
which could be used for rendering Flex apps in HTML5 later on. The
approach could be based on the UI/component implementation OpenLaszlo
has (which provides cross-compilation features for ActionScript and
JavaScript, check this demo):
http://vimeo.com/32853986
HTML5 version http://www.openlaszlo.org/lps_demos/demos/lzpix/app.lzx?lzr=dhtml
SWF version http://www.openlaszlo.org/lps_demos/demos/lzpix/app.lzx?lzr=swf10

2012/1/4 Fréderic Cox <[hidden email]>:

> And it's not only on mobile, on desktop (mostly Mac's) this is a problem
> also. I'm talking about big enterprise applications and websites here
> (like a CMS with graphical skin applied, nothing really in standard Flex
> skin)
>
> On 04/01/12 22:49, "Arthur Lockman" <[hidden email]> wrote:
>
>>+1 on this. Performance definitely needs to be addressed on Flex. I've
>>noticed that on newer devices, it works fine. But on the slightly older
>>ones, performance is a huge issue. Hopefully we can get in there and
>>clean it up so it performs better.
>>
>>
>>--
>>Arthur Lockman | Senior Developer @ Vivace
>>vi.vace.me
>>Twitter: @arthurlockman
>>a.rthr.me
>>
>>
>>On Wednesday, January 4, 2012 at 4:28 PM, Fréderic Cox wrote:
>>
>>> I've worked on Flex applications for the past 4-5 years and see a lot
>>>of developers picking it up since it is easy to create rich
>>>applications. However performance is often an issue.
>>>
>>> I mostly see it when using a lot of styles (or one large CSS file) and
>>>skinned components (It is even worse with Flex 4 then it was with Flex
>>>3). When a Flex application gets really large the UI is blocked because
>>>there is too much actionscript code needed to get things running. (with
>>>this I mean the processing time is acceptable but UI is blocked so the
>>>perception is that things are slow)
>>>
>>> Therefore I'd like to vote on improving the performance of the Flex
>>>framework where possible so new and existing applications can benefit.
>>>Flex 4 with spark is great but comes with some performance drawbacks, I
>>>hope we can improve on this significantly.
>>>
>>> I'm speaking on behalf of the experience and perception in the company
>>>I work for, I'm curious to see if this is also a problem for the rest of
>>>you.
>>>
>>> I'm not the expert here but I'd like to get involved and learn so I can
>>>eventually help to fix issues but I believe UIComponent had some
>>>overhead and this together with the StyleManager can cause performance
>>>drawbacks in large applications
>>
>



--
-----------------------------------------------------------------

Raju Bitter | Software Architect
cell: +49 (0) 176 322 011 96
fax: +49 (0) 8821 68 69 08 29
email: [hidden email]
Germany

Reply | Threaded
Open this post in threaded view
|

Re: Flex performance

Iwo Banaś
In reply to this post by Jeffry Houser
The Flex framework is a big beast but from my experience whichever
part you pick it can be optimized :-)

The biggest issue with StyleManager is scalability, it's fast for
small toy projects and simple examples but terribly slow for huge
applications.The problem is that styles processing times grows with
number of selectors/depth of the display list/inheritance tree etc.

I'll post a more detailed description of StyleManager issues and
possible solutions in couple days.

Many of performance issues can be addressed but to be sure that we are
addressing the right ones we'll need a good performance benchmarks.
Preferably a full enterprise applications. I'm aware that it's not
possible to release commercial application code as a benchmark but we
may create a SDK version with performance monitoring and encourage
people to run it against their projects and post back the analysis.
Such approach is much more efficient than creating a "add 1000
UIComponents to display list" kind of tests.

Cheers,
Iwo Banas



On 4 January 2012 21:56, Jeffry Houser <[hidden email]> wrote:

>
>  I agree with the sentiment, but I don't think that "performance" is an
> actionable item.  The Flex Framework is a big beast; what exactly do you
> want to improve performance of?
>
>  If you were to say that "I want views in a mobile web app to change quicker
> when using a viewChange effect" that would be something specific someone
> could look into.
>
>  Or you could say "I want improved performance when using binding inside an
> in-line itemRenderer"
>
>  I have solved a lot of "memory/performance" issues for Flextras clients
> over the years strictly by re-writing their itemRenderers to not use
> bindings, but to instead respond to the dataChange event.
>
>
> On 1/4/2012 4:49 PM, Arthur Lockman wrote:
>>
>> +1 on this. Performance definitely needs to be addressed on Flex. I've
>> noticed that on newer devices, it works fine. But on the slightly older
>> ones, performance is a huge issue. Hopefully we can get in there and clean
>> it up so it performs better.
>>
>>
>> --
>> Arthur Lockman | Senior Developer @ Vivace
>> vi.vace.me
>> Twitter: @arthurlockman
>> a.rthr.me
>>
>>
>> On Wednesday, January 4, 2012 at 4:28 PM, Fréderic Cox wrote:
>>
>>> I've worked on Flex applications for the past 4-5 years and see a lot of
>>> developers picking it up since it is easy to create rich applications.
>>> However performance is often an issue.
>>>
>>> I mostly see it when using a lot of styles (or one large CSS file) and
>>> skinned components (It is even worse with Flex 4 then it was with Flex 3).
>>> When a Flex application gets really large the UI is blocked because there is
>>> too much actionscript code needed to get things running. (with this I mean
>>> the processing time is acceptable but UI is blocked so the perception is
>>> that things are slow)
>>>
>>> Therefore I'd like to vote on improving the performance of the Flex
>>> framework where possible so new and existing applications can benefit. Flex
>>> 4 with spark is great but comes with some performance drawbacks, I hope we
>>> can improve on this significantly.
>>>
>>> I'm speaking on behalf of the experience and perception in the company I
>>> work for, I'm curious to see if this is also a problem for the rest of you.
>>>
>>> I'm not the expert here but I'd like to get involved and learn so I can
>>> eventually help to fix issues but I believe UIComponent had some overhead
>>> and this together with the StyleManager can cause performance drawbacks in
>>> large applications
>>
>>
>
>
> --
> Jeffry Houser
> Technical Entrepreneur
> 203-379-0773
> --
> http://www.flextras.com?c=104
> UI Flex Components: Tested! Supported! Ready!
> --
> http://www.theflexshow.com
> http://www.jeffryhouser.com
> http://www.asktheflexpert.com
> --
> Part of the DotComIt Brain Trust
>

Reply | Threaded
Open this post in threaded view
|

Re: Flex performance

Jonathan Campos
If someone was so inclined they could create some intentionally complicated
application that allows you to view mailing list messages or some app to
that effect. Then with this shared (and possibly helpful) app we could beat
against it for performance.

Just a wild idea.

On Wed, Jan 4, 2012 at 4:23 PM, Iwo Banaś <[hidden email]> wrote:

> The Flex framework is a big beast but from my experience whichever
> part you pick it can be optimized :-)
>
> The biggest issue with StyleManager is scalability, it's fast for
> small toy projects and simple examples but terribly slow for huge
> applications.The problem is that styles processing times grows with
> number of selectors/depth of the display list/inheritance tree etc.
>
> I'll post a more detailed description of StyleManager issues and
> possible solutions in couple days.
>
> Many of performance issues can be addressed but to be sure that we are
> addressing the right ones we'll need a good performance benchmarks.
> Preferably a full enterprise applications. I'm aware that it's not
> possible to release commercial application code as a benchmark but we
> may create a SDK version with performance monitoring and encourage
> people to run it against their projects and post back the analysis.
> Such approach is much more efficient than creating a "add 1000
> UIComponents to display list" kind of tests.
>
> Cheers,
> Iwo Banas
>
>
>
> On 4 January 2012 21:56, Jeffry Houser <[hidden email]> wrote:
> >
> >  I agree with the sentiment, but I don't think that "performance" is an
> > actionable item.  The Flex Framework is a big beast; what exactly do you
> > want to improve performance of?
> >
> >  If you were to say that "I want views in a mobile web app to change
> quicker
> > when using a viewChange effect" that would be something specific someone
> > could look into.
> >
> >  Or you could say "I want improved performance when using binding inside
> an
> > in-line itemRenderer"
> >
> >  I have solved a lot of "memory/performance" issues for Flextras clients
> > over the years strictly by re-writing their itemRenderers to not use
> > bindings, but to instead respond to the dataChange event.
> >
> >
> > On 1/4/2012 4:49 PM, Arthur Lockman wrote:
> >>
> >> +1 on this. Performance definitely needs to be addressed on Flex. I've
> >> noticed that on newer devices, it works fine. But on the slightly older
> >> ones, performance is a huge issue. Hopefully we can get in there and
> clean
> >> it up so it performs better.
> >>
> >>
> >> --
> >> Arthur Lockman | Senior Developer @ Vivace
> >> vi.vace.me
> >> Twitter: @arthurlockman
> >> a.rthr.me
> >>
> >>
> >> On Wednesday, January 4, 2012 at 4:28 PM, Fréderic Cox wrote:
> >>
> >>> I've worked on Flex applications for the past 4-5 years and see a lot
> of
> >>> developers picking it up since it is easy to create rich applications.
> >>> However performance is often an issue.
> >>>
> >>> I mostly see it when using a lot of styles (or one large CSS file) and
> >>> skinned components (It is even worse with Flex 4 then it was with Flex
> 3).
> >>> When a Flex application gets really large the UI is blocked because
> there is
> >>> too much actionscript code needed to get things running. (with this I
> mean
> >>> the processing time is acceptable but UI is blocked so the perception
> is
> >>> that things are slow)
> >>>
> >>> Therefore I'd like to vote on improving the performance of the Flex
> >>> framework where possible so new and existing applications can benefit.
> Flex
> >>> 4 with spark is great but comes with some performance drawbacks, I
> hope we
> >>> can improve on this significantly.
> >>>
> >>> I'm speaking on behalf of the experience and perception in the company
> I
> >>> work for, I'm curious to see if this is also a problem for the rest of
> you.
> >>>
> >>> I'm not the expert here but I'd like to get involved and learn so I can
> >>> eventually help to fix issues but I believe UIComponent had some
> overhead
> >>> and this together with the StyleManager can cause performance
> drawbacks in
> >>> large applications
> >>
> >>
> >
> >
> > --
> > Jeffry Houser
> > Technical Entrepreneur
> > 203-379-0773
> > --
> > http://www.flextras.com?c=104
> > UI Flex Components: Tested! Supported! Ready!
> > --
> > http://www.theflexshow.com
> > http://www.jeffryhouser.com
> > http://www.asktheflexpert.com
> > --
> > Part of the DotComIt Brain Trust
> >
>



--
Jonathan Campos
Dallas Flex User Group Manager
http://www.d-flex.org/
blog: http://www.unitedmindset.com/jonbcampos
twitter: http://www.twitter.com/jonbcampos
Reply | Threaded
Open this post in threaded view
|

Re: Flex performance

Alex Harui
In reply to this post by Fréderic Cox
The large CSS file issue should be resolved in 4.6.  And Ryan will likely
submit another patch that makes it even better during state transitions.

It is important to profile your application to understanding why you are
having performance problems.   Sure, UIComponent can be refactored and
become more lightweight, but are you sure that's going to speed up our app?
Is the styles subsystem just slow or do you have too many display objects
off screen in your app?

That said, I hope to find time to start a discussion soon about my vision
for what should happen for Flex in Apache.

On 1/4/12 2:07 PM, "Fréderic Cox" <[hidden email]> wrote:

> There will be numerous smaller things to tackle of course, I just wanted
> this general topic started to get some feedback.
>
> - I want UIComponent to be more lightweight
> - I want to reduce the performance cost of using styles and style
> selectors/descendants
> - I don't want UI to get blocked because of actionscript execution but use
> workers or threading baked inside of the framework
>
> Those are more specific cases like you mention where we can focus on
>
> I avoid binding as much as I can because of the performance overhead, but
> in a lot of samples it was used because it is 'fast to develop with' to
> get people excited about Flex though it should be avoided if possible in
> larger projects
>
> On 04/01/12 22:56, "Jeffry Houser" <[hidden email]> wrote:
>
>>
>>  I agree with the sentiment, but I don't think that "performance" is an
>> actionable item.  The Flex Framework is a big beast; what exactly do you
>> want to improve performance of?
>>
>>  If you were to say that "I want views in a mobile web app to change
>> quicker when using a viewChange effect" that would be something specific
>> someone could look into.
>>
>>  Or you could say "I want improved performance when using binding
>> inside an in-line itemRenderer"
>>
>>  I have solved a lot of "memory/performance" issues for Flextras
>> clients over the years strictly by re-writing their itemRenderers to not
>> use bindings, but to instead respond to the dataChange event.
>>
>> On 1/4/2012 4:49 PM, Arthur Lockman wrote:
>>> +1 on this. Performance definitely needs to be addressed on Flex. I've
>>> noticed that on newer devices, it works fine. But on the slightly older
>>> ones, performance is a huge issue. Hopefully we can get in there and
>>> clean it up so it performs better.
>>>
>>>
>>> --
>>> Arthur Lockman | Senior Developer @ Vivace
>>> vi.vace.me
>>> Twitter: @arthurlockman
>>> a.rthr.me
>>>
>>>
>>> On Wednesday, January 4, 2012 at 4:28 PM, Fréderic Cox wrote:
>>>
>>>> I've worked on Flex applications for the past 4-5 years and see a lot
>>>> of developers picking it up since it is easy to create rich
>>>> applications. However performance is often an issue.
>>>>
>>>> I mostly see it when using a lot of styles (or one large CSS file) and
>>>> skinned components (It is even worse with Flex 4 then it was with Flex
>>>> 3). When a Flex application gets really large the UI is blocked because
>>>> there is too much actionscript code needed to get things running. (with
>>>> this I mean the processing time is acceptable but UI is blocked so the
>>>> perception is that things are slow)
>>>>
>>>> Therefore I'd like to vote on improving the performance of the Flex
>>>> framework where possible so new and existing applications can benefit.
>>>> Flex 4 with spark is great but comes with some performance drawbacks, I
>>>> hope we can improve on this significantly.
>>>>
>>>> I'm speaking on behalf of the experience and perception in the company
>>>> I work for, I'm curious to see if this is also a problem for the rest
>>>> of you.
>>>>
>>>> I'm not the expert here but I'd like to get involved and learn so I
>>>> can eventually help to fix issues but I believe UIComponent had some
>>>> overhead and this together with the StyleManager can cause performance
>>>> drawbacks in large applications
>>>
>>
>>
>> --
>> Jeffry Houser
>> Technical Entrepreneur
>> 203-379-0773
>> --
>> http://www.flextras.com?c=104
>> UI Flex Components: Tested! Supported! Ready!
>> --
>> http://www.theflexshow.com
>> http://www.jeffryhouser.com
>> http://www.asktheflexpert.com
>> --
>> Part of the DotComIt Brain Trust
>>
>

--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui


Reply | Threaded
Open this post in threaded view
|

Re: Flex performance

Jeffry Houser
In reply to this post by Raju Bitter

  Has open Laszlo stayed up to date?  I hadn't heard of it in many years.

  I--personally--would  rather see efforts put towards optimizing
existing Flex Components or the component framework; not on creating a
3rd component framework within Flex.

On 1/4/2012 5:10 PM, Raju Bitter wrote:

> It would make sense to build a light-weight component set for Flex,
> which could be used for rendering Flex apps in HTML5 later on. The
> approach could be based on the UI/component implementation OpenLaszlo
> has (which provides cross-compilation features for ActionScript and
> JavaScript, check this demo):
> http://vimeo.com/32853986
> HTML5 version http://www.openlaszlo.org/lps_demos/demos/lzpix/app.lzx?lzr=dhtml
> SWF version http://www.openlaszlo.org/lps_demos/demos/lzpix/app.lzx?lzr=swf10
>
> 2012/1/4 Fréderic Cox<[hidden email]>:
>> And it's not only on mobile, on desktop (mostly Mac's) this is a problem
>> also. I'm talking about big enterprise applications and websites here
>> (like a CMS with graphical skin applied, nothing really in standard Flex
>> skin)
>>
>> On 04/01/12 22:49, "Arthur Lockman"<[hidden email]>  wrote:
>>
>>> +1 on this. Performance definitely needs to be addressed on Flex. I've
>>> noticed that on newer devices, it works fine. But on the slightly older
>>> ones, performance is a huge issue. Hopefully we can get in there and
>>> clean it up so it performs better.
>>>
>>>
>>> --
>>> Arthur Lockman | Senior Developer @ Vivace
>>> vi.vace.me
>>> Twitter: @arthurlockman
>>> a.rthr.me
>>>
>>>
>>> On Wednesday, January 4, 2012 at 4:28 PM, Fréderic Cox wrote:
>>>
>>>> I've worked on Flex applications for the past 4-5 years and see a lot
>>>> of developers picking it up since it is easy to create rich
>>>> applications. However performance is often an issue.
>>>>
>>>> I mostly see it when using a lot of styles (or one large CSS file) and
>>>> skinned components (It is even worse with Flex 4 then it was with Flex
>>>> 3). When a Flex application gets really large the UI is blocked because
>>>> there is too much actionscript code needed to get things running. (with
>>>> this I mean the processing time is acceptable but UI is blocked so the
>>>> perception is that things are slow)
>>>>
>>>> Therefore I'd like to vote on improving the performance of the Flex
>>>> framework where possible so new and existing applications can benefit.
>>>> Flex 4 with spark is great but comes with some performance drawbacks, I
>>>> hope we can improve on this significantly.
>>>>
>>>> I'm speaking on behalf of the experience and perception in the company
>>>> I work for, I'm curious to see if this is also a problem for the rest of
>>>> you.
>>>>
>>>> I'm not the expert here but I'd like to get involved and learn so I can
>>>> eventually help to fix issues but I believe UIComponent had some
>>>> overhead and this together with the StyleManager can cause performance
>>>> drawbacks in large applications
>
>


--
Jeffry Houser
Technical Entrepreneur
203-379-0773
--
http://www.flextras.com?c=104
UI Flex Components: Tested! Supported! Ready!
--
http://www.theflexshow.com
http://www.jeffryhouser.com
http://www.asktheflexpert.com
--
Part of the DotComIt Brain Trust


Reply | Threaded
Open this post in threaded view
|

Re: Flex performance

João Fernandes
In reply to this post by Iwo Banaś
  On 1/4/2012 10:23 PM, Iwo Banaś wrote:
> Many of performance issues can be addressed but to be sure that we are
> addressing the right ones we'll need a good performance benchmarks.
> Preferably a full enterprise applications. I'm aware that it's not
> possible to release commercial application code as a benchmark but we
> may create a SDK version with performance monitoring and encourage
> people to run it against their projects and post back the analysis.
> Such approach is much more efficient than creating a "add 1000
> UIComponents to display list" kind of tests.
I could provide analysis from our application (ERP system with around
300k lines and growing) using this kind of performance monitor if it can
help tracking performance issues.

João Fernandes

Reply | Threaded
Open this post in threaded view
|

Re: Flex performance

Jonathan Campos
In reply to this post by Jeffry Houser
Just to be fair. If they want to make another set of Components that is
completely their choice. Sorry Jeff for responding with this to your post,
just see lots of people talking about what should and should not be done.
We all have to remember that some  people's passions may be in a different
direction then what we believe and that is perfectly okay.

I can't say that everyone's passion will be accepted into the trunk, but
you are more than happy to work on it.

On Wed, Jan 4, 2012 at 4:37 PM, Jeffry Houser <[hidden email]> wrote:

>
>  Has open Laszlo stayed up to date?  I hadn't heard of it in many years.
>
>  I--personally--would  rather see efforts put towards optimizing existing
> Flex Components or the component framework; not on creating a 3rd component
> framework within Flex.
>
>
> On 1/4/2012 5:10 PM, Raju Bitter wrote:
>
>> It would make sense to build a light-weight component set for Flex,
>> which could be used for rendering Flex apps in HTML5 later on. The
>> approach could be based on the UI/component implementation OpenLaszlo
>> has (which provides cross-compilation features for ActionScript and
>> JavaScript, check this demo):
>> http://vimeo.com/32853986
>> HTML5 version http://www.openlaszlo.org/lps_**
>> demos/demos/lzpix/app.lzx?lzr=**dhtml<http://www.openlaszlo.org/lps_demos/demos/lzpix/app.lzx?lzr=dhtml>
>> SWF version http://www.openlaszlo.org/lps_**
>> demos/demos/lzpix/app.lzx?lzr=**swf10<http://www.openlaszlo.org/lps_demos/demos/lzpix/app.lzx?lzr=swf10>
>>
>> 2012/1/4 Fréderic Cox<[hidden email]>:
>>
>>> And it's not only on mobile, on desktop (mostly Mac's) this is a problem
>>> also. I'm talking about big enterprise applications and websites here
>>> (like a CMS with graphical skin applied, nothing really in standard Flex
>>> skin)
>>>
>>> On 04/01/12 22:49, "Arthur Lockman"<arthurlockman@ajobi.**net<[hidden email]>>
>>>  wrote:
>>>
>>>  +1 on this. Performance definitely needs to be addressed on Flex. I've
>>>> noticed that on newer devices, it works fine. But on the slightly older
>>>> ones, performance is a huge issue. Hopefully we can get in there and
>>>> clean it up so it performs better.
>>>>
>>>>
>>>> --
>>>> Arthur Lockman | Senior Developer @ Vivace
>>>> vi.vace.me
>>>> Twitter: @arthurlockman
>>>> a.rthr.me
>>>>
>>>>
>>>> On Wednesday, January 4, 2012 at 4:28 PM, Fréderic Cox wrote:
>>>>
>>>>  I've worked on Flex applications for the past 4-5 years and see a lot
>>>>> of developers picking it up since it is easy to create rich
>>>>> applications. However performance is often an issue.
>>>>>
>>>>> I mostly see it when using a lot of styles (or one large CSS file) and
>>>>> skinned components (It is even worse with Flex 4 then it was with Flex
>>>>> 3). When a Flex application gets really large the UI is blocked because
>>>>> there is too much actionscript code needed to get things running. (with
>>>>> this I mean the processing time is acceptable but UI is blocked so the
>>>>> perception is that things are slow)
>>>>>
>>>>> Therefore I'd like to vote on improving the performance of the Flex
>>>>> framework where possible so new and existing applications can benefit.
>>>>> Flex 4 with spark is great but comes with some performance drawbacks, I
>>>>> hope we can improve on this significantly.
>>>>>
>>>>> I'm speaking on behalf of the experience and perception in the company
>>>>> I work for, I'm curious to see if this is also a problem for the rest
>>>>> of
>>>>> you.
>>>>>
>>>>> I'm not the expert here but I'd like to get involved and learn so I can
>>>>> eventually help to fix issues but I believe UIComponent had some
>>>>> overhead and this together with the StyleManager can cause performance
>>>>> drawbacks in large applications
>>>>>
>>>>
>>
>>
>
> --
> Jeffry Houser
> Technical Entrepreneur
> 203-379-0773
> --
> http://www.flextras.com?c=104
> UI Flex Components: Tested! Supported! Ready!
> --
> http://www.theflexshow.com
> http://www.jeffryhouser.com
> http://www.asktheflexpert.com
> --
> Part of the DotComIt Brain Trust
>
>


--
Jonathan Campos
Dallas Flex User Group Manager
http://www.d-flex.org/
blog: http://www.unitedmindset.com/jonbcampos
twitter: http://www.twitter.com/jonbcampos
Reply | Threaded
Open this post in threaded view
|

Re: Flex performance

Fréderic Cox
In reply to this post by João Fernandes
I have a CMS which consists of 10-15 modules with dynamic skinning (3
skins based on rolloutID the style.swf for the relevant project will be
loaded at runtime) and there has been a lot of work done by inexperienced
developers (following code guidelines with good testing but focus was on
getting it to work and to lesser extent on good code), also loading a lot
of data (5000 complex items) and lots of seperate AMFPHP calls it is a
very intensive RIA. It works pretty fast now but it could be faster on mac
(not blocking UI)

Afterwards I optimized it (and still am) but that would be useful for
performance analytics (before and after) also. I'll check on what exactly
is expensive in the profiler (I will try to use Flex 4.6 first if it
compiles to that)

On 04/01/12 23:42, "João Fernandes" <[hidden email]>
wrote:

>  On 1/4/2012 10:23 PM, Iwo Banaś wrote:
>> Many of performance issues can be addressed but to be sure that we are
>> addressing the right ones we'll need a good performance benchmarks.
>> Preferably a full enterprise applications. I'm aware that it's not
>> possible to release commercial application code as a benchmark but we
>> may create a SDK version with performance monitoring and encourage
>> people to run it against their projects and post back the analysis.
>> Such approach is much more efficient than creating a "add 1000
>> UIComponents to display list" kind of tests.
>I could provide analysis from our application (ERP system with around
>300k lines and growing) using this kind of performance monitor if it can
>help tracking performance issues.
>
>João Fernandes

Reply | Threaded
Open this post in threaded view
|

Re: Flex performance

Jeffry Houser
In reply to this post by Jonathan Campos

  No argument.

  I'd like to think I was clearly expressing personal preference, not
dictating other people's actions.

On 1/4/2012 5:44 PM, Jonathan Campos wrote:

> Just to be fair. If they want to make another set of Components that
> is completely their choice. Sorry Jeff for responding with this to
> your post, just see lots of people talking about what should and
> should not be done. We all have to remember that some  people's
> passions may be in a different direction then what we believe and that
> is perfectly okay.
>
> I can't say that everyone's passion will be accepted into the trunk,
> but you are more than happy to work on it.
>
> On Wed, Jan 4, 2012 at 4:37 PM, Jeffry Houser <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>
>      Has open Laszlo stayed up to date?  I hadn't heard of it in many
>     years.
>
>      I--personally--would  rather see efforts put towards optimizing
>     existing Flex Components or the component framework; not on
>     creating a 3rd component framework within Flex.
>
>
>     On 1/4/2012 5:10 PM, Raju Bitter wrote:
>
>         It would make sense to build a light-weight component set for
>         Flex,
>         which could be used for rendering Flex apps in HTML5 later on. The
>         approach could be based on the UI/component implementation
>         OpenLaszlo
>         has (which provides cross-compilation features for
>         ActionScript and
>         JavaScript, check this demo):
>         http://vimeo.com/32853986
>         HTML5 version
>         http://www.openlaszlo.org/lps_demos/demos/lzpix/app.lzx?lzr=dhtml
>         SWF version
>         http://www.openlaszlo.org/lps_demos/demos/lzpix/app.lzx?lzr=swf10
>
>         2012/1/4 Fréderic Cox<[hidden email]
>         <mailto:[hidden email]>>:
>
>             And it's not only on mobile, on desktop (mostly Mac's)
>             this is a problem
>             also. I'm talking about big enterprise applications and
>             websites here
>             (like a CMS with graphical skin applied, nothing really in
>             standard Flex
>             skin)
>
>             On 04/01/12 22:49, "Arthur
>             Lockman"<[hidden email]
>             <mailto:[hidden email]>>  wrote:
>
>                 +1 on this. Performance definitely needs to be
>                 addressed on Flex. I've
>                 noticed that on newer devices, it works fine. But on
>                 the slightly older
>                 ones, performance is a huge issue. Hopefully we can
>                 get in there and
>                 clean it up so it performs better.
>
>
>                 --
>                 Arthur Lockman | Senior Developer @ Vivace
>                 vi.vace.me <http://vi.vace.me>
>                 Twitter: @arthurlockman
>                 a.rthr.me <http://a.rthr.me>
>
>
>                 On Wednesday, January 4, 2012 at 4:28 PM, Fréderic Cox
>                 wrote:
>
>                     I've worked on Flex applications for the past 4-5
>                     years and see a lot
>                     of developers picking it up since it is easy to
>                     create rich
>                     applications. However performance is often an issue.
>
>                     I mostly see it when using a lot of styles (or one
>                     large CSS file) and
>                     skinned components (It is even worse with Flex 4
>                     then it was with Flex
>                     3). When a Flex application gets really large the
>                     UI is blocked because
>                     there is too much actionscript code needed to get
>                     things running. (with
>                     this I mean the processing time is acceptable but
>                     UI is blocked so the
>                     perception is that things are slow)
>
>                     Therefore I'd like to vote on improving the
>                     performance of the Flex
>                     framework where possible so new and existing
>                     applications can benefit.
>                     Flex 4 with spark is great but comes with some
>                     performance drawbacks, I
>                     hope we can improve on this significantly.
>
>                     I'm speaking on behalf of the experience and
>                     perception in the company
>                     I work for, I'm curious to see if this is also a
>                     problem for the rest of
>                     you.
>
>                     I'm not the expert here but I'd like to get
>                     involved and learn so I can
>                     eventually help to fix issues but I believe
>                     UIComponent had some
>                     overhead and this together with the StyleManager
>                     can cause performance
>                     drawbacks in large applications
>
>
>
>
>
>     --
>     Jeffry Houser
>     Technical Entrepreneur
>     203-379-0773 <tel:203-379-0773>
>     --
>     http://www.flextras.com?c=104
>     UI Flex Components: Tested! Supported! Ready!
>     --
>     http://www.theflexshow.com
>     http://www.jeffryhouser.com
>     http://www.asktheflexpert.com
>     --
>     Part of the DotComIt Brain Trust
>
>
>
>
> --
> Jonathan Campos
> Dallas Flex User Group Manager
> http://www.d-flex.org/
> blog: http://www.unitedmindset.com/jonbcampos
> twitter: http://www.twitter.com/jonbcampos


--
Jeffry Houser
Technical Entrepreneur
203-379-0773
--
http://www.flextras.com?c=104
UI Flex Components: Tested! Supported! Ready!
--
http://www.theflexshow.com
http://www.jeffryhouser.com
http://www.asktheflexpert.com
--
Part of the DotComIt Brain Trust

Reply | Threaded
Open this post in threaded view
|

Re: Flex performance

Jonathan Campos
And you did. I made sure to apologize early to you because it wasn't your
comment, but just general comments of first priorities and what is
important. My worry is that some of these discussions hinder someone that
may come in that doesn't feel like they can help rearchitect the framework,
but just has a null-pointer fix to some component. I would worry that
someone would read these posts - which are all meant to be very positive
and get everyone rallied together - and worry that this is not a place for
them.

I just want to make sure that everyone is welcome.

On Wed, Jan 4, 2012 at 5:05 PM, Jeffry Houser <[hidden email]> wrote:

>
>  No argument.
>
>  I'd like to think I was clearly expressing personal preference, not
> dictating other people's actions.
>
>
> On 1/4/2012 5:44 PM, Jonathan Campos wrote:
>
>> Just to be fair. If they want to make another set of Components that is
>> completely their choice. Sorry Jeff for responding with this to your post,
>> just see lots of people talking about what should and should not be done.
>> We all have to remember that some  people's passions may be in a different
>> direction then what we believe and that is perfectly okay.
>>
>> I can't say that everyone's passion will be accepted into the trunk, but
>> you are more than happy to work on it.
>>
>> On Wed, Jan 4, 2012 at 4:37 PM, Jeffry Houser <[hidden email]<mailto:
>> [hidden email]>**> wrote:
>>
>>
>>     Has open Laszlo stayed up to date?  I hadn't heard of it in many
>>    years.
>>
>>     I--personally--would  rather see efforts put towards optimizing
>>    existing Flex Components or the component framework; not on
>>    creating a 3rd component framework within Flex.
>>
>>
>>    On 1/4/2012 5:10 PM, Raju Bitter wrote:
>>
>>        It would make sense to build a light-weight component set for
>>        Flex,
>>        which could be used for rendering Flex apps in HTML5 later on. The
>>        approach could be based on the UI/component implementation
>>        OpenLaszlo
>>        has (which provides cross-compilation features for
>>        ActionScript and
>>        JavaScript, check this demo):
>>        http://vimeo.com/32853986
>>        HTML5 version
>>        http://www.openlaszlo.org/lps_**demos/demos/lzpix/app.lzx?lzr=**
>> dhtml <http://www.openlaszlo.org/lps_demos/demos/lzpix/app.lzx?lzr=dhtml>
>>        SWF version
>>        http://www.openlaszlo.org/lps_**demos/demos/lzpix/app.lzx?lzr=**
>> swf10 <http://www.openlaszlo.org/lps_demos/demos/lzpix/app.lzx?lzr=swf10>
>>
>>        2012/1/4 Fréderic Cox<[hidden email]
>>        <mailto:[hidden email]>>:
>>
>>
>>            And it's not only on mobile, on desktop (mostly Mac's)
>>            this is a problem
>>            also. I'm talking about big enterprise applications and
>>            websites here
>>            (like a CMS with graphical skin applied, nothing really in
>>            standard Flex
>>            skin)
>>
>>            On 04/01/12 22:49, "Arthur
>>            Lockman"<arthurlockman@ajobi.**net <[hidden email]>
>>            <mailto:arthurlockman@ajobi.**net <[hidden email]>>>
>>  wrote:
>>
>>
>>                +1 on this. Performance definitely needs to be
>>                addressed on Flex. I've
>>                noticed that on newer devices, it works fine. But on
>>                the slightly older
>>                ones, performance is a huge issue. Hopefully we can
>>                get in there and
>>                clean it up so it performs better.
>>
>>
>>                --
>>                Arthur Lockman | Senior Developer @ Vivace
>>                vi.vace.me <http://vi.vace.me>
>>                Twitter: @arthurlockman
>>                a.rthr.me <http://a.rthr.me>
>>
>>
>>
>>                On Wednesday, January 4, 2012 at 4:28 PM, Fréderic Cox
>>                wrote:
>>
>>                    I've worked on Flex applications for the past 4-5
>>                    years and see a lot
>>                    of developers picking it up since it is easy to
>>                    create rich
>>                    applications. However performance is often an issue.
>>
>>                    I mostly see it when using a lot of styles (or one
>>                    large CSS file) and
>>                    skinned components (It is even worse with Flex 4
>>                    then it was with Flex
>>                    3). When a Flex application gets really large the
>>                    UI is blocked because
>>                    there is too much actionscript code needed to get
>>                    things running. (with
>>                    this I mean the processing time is acceptable but
>>                    UI is blocked so the
>>                    perception is that things are slow)
>>
>>                    Therefore I'd like to vote on improving the
>>                    performance of the Flex
>>                    framework where possible so new and existing
>>                    applications can benefit.
>>                    Flex 4 with spark is great but comes with some
>>                    performance drawbacks, I
>>                    hope we can improve on this significantly.
>>
>>                    I'm speaking on behalf of the experience and
>>                    perception in the company
>>                    I work for, I'm curious to see if this is also a
>>                    problem for the rest of
>>                    you.
>>
>>                    I'm not the expert here but I'd like to get
>>                    involved and learn so I can
>>                    eventually help to fix issues but I believe
>>                    UIComponent had some
>>                    overhead and this together with the StyleManager
>>                    can cause performance
>>                    drawbacks in large applications
>>
>>
>>
>>
>>
>>    --     Jeffry Houser
>>    Technical Entrepreneur
>>    203-379-0773 <tel:203-379-0773>
>>
>>    --
>>    http://www.flextras.com?c=104
>>    UI Flex Components: Tested! Supported! Ready!
>>    --
>>    http://www.theflexshow.com
>>    http://www.jeffryhouser.com
>>    http://www.asktheflexpert.com
>>    --
>>    Part of the DotComIt Brain Trust
>>
>>
>>
>>
>> --
>> Jonathan Campos
>> Dallas Flex User Group Manager
>> http://www.d-flex.org/
>> blog: http://www.unitedmindset.com/**jonbcampos<http://www.unitedmindset.com/jonbcampos>
>> twitter: http://www.twitter.com/**jonbcampos<http://www.twitter.com/jonbcampos>
>>
>
>
> --
> Jeffry Houser
> Technical Entrepreneur
> 203-379-0773
> --
> http://www.flextras.com?c=104
> UI Flex Components: Tested! Supported! Ready!
> --
> http://www.theflexshow.com
> http://www.jeffryhouser.com
> http://www.asktheflexpert.com
> --
> Part of the DotComIt Brain Trust
>
>


--
Jonathan Campos
Dallas Flex User Group Manager
http://www.d-flex.org/
blog: http://www.unitedmindset.com/jonbcampos
twitter: http://www.twitter.com/jonbcampos
Reply | Threaded
Open this post in threaded view
|

Re: Flex performance

Jonathan Campos
I'm probably worrying about this a bit too early and I know I've violated
this a bit also. I'm going to watch what I say.

On Wed, Jan 4, 2012 at 5:10 PM, Jonathan Campos <[hidden email]>wrote:

> And you did. I made sure to apologize early to you because it wasn't your
> comment, but just general comments of first priorities and what is
> important. My worry is that some of these discussions hinder someone that
> may come in that doesn't feel like they can help rearchitect the framework,
> but just has a null-pointer fix to some component. I would worry that
> someone would read these posts - which are all meant to be very positive
> and get everyone rallied together - and worry that this is not a place for
> them.
>
> I just want to make sure that everyone is welcome.
>
>
> On Wed, Jan 4, 2012 at 5:05 PM, Jeffry Houser <[hidden email]>wrote:
>
>>
>>  No argument.
>>
>>  I'd like to think I was clearly expressing personal preference, not
>> dictating other people's actions.
>>
>>
>> On 1/4/2012 5:44 PM, Jonathan Campos wrote:
>>
>>> Just to be fair. If they want to make another set of Components that is
>>> completely their choice. Sorry Jeff for responding with this to your post,
>>> just see lots of people talking about what should and should not be done.
>>> We all have to remember that some  people's passions may be in a different
>>> direction then what we believe and that is perfectly okay.
>>>
>>> I can't say that everyone's passion will be accepted into the trunk, but
>>> you are more than happy to work on it.
>>>
>>> On Wed, Jan 4, 2012 at 4:37 PM, Jeffry Houser <[hidden email]<mailto:
>>> [hidden email]>**> wrote:
>>>
>>>
>>>     Has open Laszlo stayed up to date?  I hadn't heard of it in many
>>>    years.
>>>
>>>     I--personally--would  rather see efforts put towards optimizing
>>>    existing Flex Components or the component framework; not on
>>>    creating a 3rd component framework within Flex.
>>>
>>>
>>>    On 1/4/2012 5:10 PM, Raju Bitter wrote:
>>>
>>>        It would make sense to build a light-weight component set for
>>>        Flex,
>>>        which could be used for rendering Flex apps in HTML5 later on. The
>>>        approach could be based on the UI/component implementation
>>>        OpenLaszlo
>>>        has (which provides cross-compilation features for
>>>        ActionScript and
>>>        JavaScript, check this demo):
>>>        http://vimeo.com/32853986
>>>        HTML5 version
>>>        http://www.openlaszlo.org/lps_**demos/demos/lzpix/app.lzx?lzr=**
>>> dhtml<http://www.openlaszlo.org/lps_demos/demos/lzpix/app.lzx?lzr=dhtml>
>>>        SWF version
>>>        http://www.openlaszlo.org/lps_**demos/demos/lzpix/app.lzx?lzr=**
>>> swf10<http://www.openlaszlo.org/lps_demos/demos/lzpix/app.lzx?lzr=swf10>
>>>
>>>        2012/1/4 Fréderic Cox<[hidden email]
>>>        <mailto:[hidden email]>>:
>>>
>>>
>>>            And it's not only on mobile, on desktop (mostly Mac's)
>>>            this is a problem
>>>            also. I'm talking about big enterprise applications and
>>>            websites here
>>>            (like a CMS with graphical skin applied, nothing really in
>>>            standard Flex
>>>            skin)
>>>
>>>            On 04/01/12 22:49, "Arthur
>>>            Lockman"<arthurlockman@ajobi.**net <[hidden email]>
>>>            <mailto:arthurlockman@ajobi.**net <[hidden email]>>>
>>>  wrote:
>>>
>>>
>>>                +1 on this. Performance definitely needs to be
>>>                addressed on Flex. I've
>>>                noticed that on newer devices, it works fine. But on
>>>                the slightly older
>>>                ones, performance is a huge issue. Hopefully we can
>>>                get in there and
>>>                clean it up so it performs better.
>>>
>>>
>>>                --
>>>                Arthur Lockman | Senior Developer @ Vivace
>>>                vi.vace.me <http://vi.vace.me>
>>>                Twitter: @arthurlockman
>>>                a.rthr.me <http://a.rthr.me>
>>>
>>>
>>>
>>>                On Wednesday, January 4, 2012 at 4:28 PM, Fréderic Cox
>>>                wrote:
>>>
>>>                    I've worked on Flex applications for the past 4-5
>>>                    years and see a lot
>>>                    of developers picking it up since it is easy to
>>>                    create rich
>>>                    applications. However performance is often an issue.
>>>
>>>                    I mostly see it when using a lot of styles (or one
>>>                    large CSS file) and
>>>                    skinned components (It is even worse with Flex 4
>>>                    then it was with Flex
>>>                    3). When a Flex application gets really large the
>>>                    UI is blocked because
>>>                    there is too much actionscript code needed to get
>>>                    things running. (with
>>>                    this I mean the processing time is acceptable but
>>>                    UI is blocked so the
>>>                    perception is that things are slow)
>>>
>>>                    Therefore I'd like to vote on improving the
>>>                    performance of the Flex
>>>                    framework where possible so new and existing
>>>                    applications can benefit.
>>>                    Flex 4 with spark is great but comes with some
>>>                    performance drawbacks, I
>>>                    hope we can improve on this significantly.
>>>
>>>                    I'm speaking on behalf of the experience and
>>>                    perception in the company
>>>                    I work for, I'm curious to see if this is also a
>>>                    problem for the rest of
>>>                    you.
>>>
>>>                    I'm not the expert here but I'd like to get
>>>                    involved and learn so I can
>>>                    eventually help to fix issues but I believe
>>>                    UIComponent had some
>>>                    overhead and this together with the StyleManager
>>>                    can cause performance
>>>                    drawbacks in large applications
>>>
>>>
>>>
>>>
>>>
>>>    --     Jeffry Houser
>>>    Technical Entrepreneur
>>>    203-379-0773 <tel:203-379-0773>
>>>
>>>    --
>>>    http://www.flextras.com?c=104
>>>    UI Flex Components: Tested! Supported! Ready!
>>>    --
>>>    http://www.theflexshow.com
>>>    http://www.jeffryhouser.com
>>>    http://www.asktheflexpert.com
>>>    --
>>>    Part of the DotComIt Brain Trust
>>>
>>>
>>>
>>>
>>> --
>>> Jonathan Campos
>>> Dallas Flex User Group Manager
>>> http://www.d-flex.org/
>>> blog: http://www.unitedmindset.com/**jonbcampos<http://www.unitedmindset.com/jonbcampos>
>>> twitter: http://www.twitter.com/**jonbcampos<http://www.twitter.com/jonbcampos>
>>>
>>
>>
>> --
>> Jeffry Houser
>> Technical Entrepreneur
>> 203-379-0773
>> --
>> http://www.flextras.com?c=104
>> UI Flex Components: Tested! Supported! Ready!
>> --
>> http://www.theflexshow.com
>> http://www.jeffryhouser.com
>> http://www.asktheflexpert.com
>> --
>> Part of the DotComIt Brain Trust
>>
>>
>
>
> --
> Jonathan Campos
> Dallas Flex User Group Manager
> http://www.d-flex.org/
> blog: http://www.unitedmindset.com/jonbcampos
> twitter: http://www.twitter.com/jonbcampos
>



--
Jonathan Campos
Dallas Flex User Group Manager
http://www.d-flex.org/
blog: http://www.unitedmindset.com/jonbcampos
twitter: http://www.twitter.com/jonbcampos
Reply | Threaded
Open this post in threaded view
|

Re: Flex performance

Raju Bitter
In reply to this post by Jeffry Houser
Hi Jeffry,

2012/1/4 Jeffry Houser <[hidden email]>:
>
>  Has open Laszlo stayed up to date?  I hadn't heard of it in many years.
The project has been maintained relatively well by Laszlo until early
2011, it seems the company has stopped development at the moment.

I wasn't thinking of using OpenLaszlo directly. But there are some
lessons which can be learned from the project if we'd want to create a
JavaScript cross-compilation feature for Flex. The approach you choose
when building components within Flex affects how easy it would be to
make the same component set (code base) run as an HTML5 app -
especially for mobile webkit.

>  I--personally--would  rather see efforts put towards optimizing existing
> Flex Components or the component framework; not on creating a 3rd component
> framework within Flex.
Agree, that will be more valuable at the moment. Just don't wouldn't
close the door for a possible HTML5 output of the Flex compiler. I'd
be willing to contribute the knowledge I have on OpenLaszlo to
investigate the possible cross-compilation of a Flex app to HTML5 -
although I'd be only able to do that for 4-5 hours per week.

- Raju

> On 1/4/2012 5:10 PM, Raju Bitter wrote:
>>
>> It would make sense to build a light-weight component set for Flex,
>> which could be used for rendering Flex apps in HTML5 later on. The
>> approach could be based on the UI/component implementation OpenLaszlo
>> has (which provides cross-compilation features for ActionScript and
>> JavaScript, check this demo):
>> http://vimeo.com/32853986
>> HTML5 version
>> http://www.openlaszlo.org/lps_demos/demos/lzpix/app.lzx?lzr=dhtml
>> SWF version
>> http://www.openlaszlo.org/lps_demos/demos/lzpix/app.lzx?lzr=swf10
>>
>> 2012/1/4 Fréderic Cox<[hidden email]>:
>>>
>>> And it's not only on mobile, on desktop (mostly Mac's) this is a problem
>>> also. I'm talking about big enterprise applications and websites here
>>> (like a CMS with graphical skin applied, nothing really in standard Flex
>>> skin)
>>>
>>> On 04/01/12 22:49, "Arthur Lockman"<[hidden email]>  wrote:
>>>
>>>> +1 on this. Performance definitely needs to be addressed on Flex. I've
>>>> noticed that on newer devices, it works fine. But on the slightly older
>>>> ones, performance is a huge issue. Hopefully we can get in there and
>>>> clean it up so it performs better.
>>>>
>>>>
>>>> --
>>>> Arthur Lockman | Senior Developer @ Vivace
>>>> vi.vace.me
>>>> Twitter: @arthurlockman
>>>> a.rthr.me
>>>>
>>>>
>>>> On Wednesday, January 4, 2012 at 4:28 PM, Fréderic Cox wrote:
>>>>
>>>>> I've worked on Flex applications for the past 4-5 years and see a lot
>>>>> of developers picking it up since it is easy to create rich
>>>>> applications. However performance is often an issue.
>>>>>
>>>>> I mostly see it when using a lot of styles (or one large CSS file) and
>>>>> skinned components (It is even worse with Flex 4 then it was with Flex
>>>>> 3). When a Flex application gets really large the UI is blocked because
>>>>> there is too much actionscript code needed to get things running. (with
>>>>> this I mean the processing time is acceptable but UI is blocked so the
>>>>> perception is that things are slow)
>>>>>
>>>>> Therefore I'd like to vote on improving the performance of the Flex
>>>>> framework where possible so new and existing applications can benefit.
>>>>> Flex 4 with spark is great but comes with some performance drawbacks, I
>>>>> hope we can improve on this significantly.
>>>>>
>>>>> I'm speaking on behalf of the experience and perception in the company
>>>>> I work for, I'm curious to see if this is also a problem for the rest
>>>>> of
>>>>> you.
>>>>>
>>>>> I'm not the expert here but I'd like to get involved and learn so I can
>>>>> eventually help to fix issues but I believe UIComponent had some
>>>>> overhead and this together with the StyleManager can cause performance
>>>>> drawbacks in large applications
>>
>>
>>
>
>
> --
> Jeffry Houser
> Technical Entrepreneur
> 203-379-0773
> --
> http://www.flextras.com?c=104
> UI Flex Components: Tested! Supported! Ready!
> --
> http://www.theflexshow.com
> http://www.jeffryhouser.com
> http://www.asktheflexpert.com
> --
> Part of the DotComIt Brain Trust
>



--
-----------------------------------------------------------------

Raju Bitter | Software Architect
cell: +49 (0) 176 322 011 96
fax: +49 (0) 8821 68 69 08 29
email: [hidden email]
Germany

Reply | Threaded
Open this post in threaded view
|

Re: Flex performance

Jeffry Houser
On 1/5/2012 5:04 AM, Raju Bitter wrote:
>>   I--personally--would  rather see efforts put towards optimizing existing
>> Flex Components or the component framework; not on creating a 3rd component
>> framework within Flex.
> Agree, that will be more valuable at the moment. Just don't wouldn't
> close the door for a possible HTML5 output of the Flex compiler.
   I'm not sure this needs a new component framework, or set of
components.  (It might, but I just don't know).  There are already two
approaches to this in "early" development.  Falcon-JS by Adobe and I
believe Michael Labriola had done some experiments around that.

--
Jeffry Houser
Technical Entrepreneur
203-379-0773
--
http://www.flextras.com?c=104
UI Flex Components: Tested! Supported! Ready!
--
http://www.theflexshow.com
http://www.jeffryhouser.com
http://www.asktheflexpert.com
--
Part of the DotComIt Brain Trust


Reply | Threaded
Open this post in threaded view
|

Re: Flex performance

Raju Bitter
2012/1/5 Jeffry Houser <[hidden email]>:
>  I'm not sure this needs a new component framework, or set of components.
>  (It might, but I just don't know).  There are already two approaches to
> this in "early" development.  Falcon-JS by Adobe and I believe Michael
> Labriola had done some experiments around that.
Don't know about Michael Labriola's work, but in the Falcon JS demo at
FlexSummit someone said that the size of the generated JavaScript code
is a total of 5mb for a simple app with a few buttons. That can be
reduced to 2.5 mb using Google Closure compiler, but 2.5 mb of JS is
still A LOT of JS code for a simple app. OpenLaszlo generates 600kb
without using Google Closure's optimization for a simple app, and the
largest apps I'm aware of with 110k+ lines of "MXML" like code will
generate into 1.8-1.9 mb of JS code with the platform.

Without knowing the details of Falcon JS it's hard to know why the
file size is so much larger with Falcon JS. I doubt that the iPad
renders a 2.5 mb JS app with a good performance (the problem is JS
parsing, not execution of the code).

12