Right. And if you're project was 1MB and you could get 10 more frames per
second out of an optimization that added 50kb then you'd want to flip that
switch. What I mean is that it's the type of choice you could add as a
compiler option. We already have to make the size vs speed vs convenience
choic
>> It sounds like a decision that has to be made by the project. For
>> mobile
>> apps size is not as much of a concern as performance.
> Probably true, but I hear lots of complaints about folks hitting some
limit the Apple Store approvers don't like.
>
> Alex Harui
> Flex SDK Developer
> Adobe Sys
> -Original Message-
> From: jude [mailto:flexcapaci...@gmail.com]
> Sent: Friday, January 27, 2012 6:01 AM
> To: flex-dev@incubator.apache.org
> Subject: Re: Optimize Flex performance
>
> It sounds like a decision that has to be made by the project. For
> mobi
l Message-
> From: James Ong [mailto:yanlile...@gmail.com]
> Sent: Wednesday, January 25, 2012 9:15 PM
> To: flex-dev@incubator.apache.org
> Subject: Optimize Flex performance
>
> As far as I see, Flex code into bytecode are not optimize for performance.
> Is there any plans for committers write efficient compiler?
>
Adobe
-Original Message-
From: Gordon Smith [mailto:gosm...@adobe.com]
Sent: Thursday, January 26, 2012 12:49 PM
To: flex-dev@incubator.apache.org
Subject: RE: Optimize Flex performance
The Falcon compiler will have some bytecode optimizations that the current
compiler doesn't do, such a
could grow
significantly.
- Gordon Smith, Adobe
-Original Message-
From: James Ong [mailto:yanlile...@gmail.com]
Sent: Wednesday, January 25, 2012 9:15 PM
To: flex-dev@incubator.apache.org
Subject: Optimize Flex performance
As far as I see, Flex code into bytecode are not optimiz
I'm betting that they're porting over the entire flash API to JS to make
conversion nearly 1:1 from an API standpoint.
2012/1/5 Jeffry Houser :
> 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.
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 doo
Hi Jeffry,
2012/1/4 Jeffry Houser :
>
> 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.
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 wrote:
> And you did. I made sure to apologize early to you because it wasn't your
> comment, but just general comments of firs
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
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 thi
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
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
dir
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
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 wo
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
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:2
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 grow
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 dem
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
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 w
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 performan
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" wrote:
>+1 on this. Performance defini
+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
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
27 matches
Mail list logo
