You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@flex.apache.org by Alex Harui <ah...@adobe.com> on 2013/01/18 20:49:22 UTC
ASJS and Starling (was Re: [FalconJx] where I'm going to be)
Changing subject because GPU rendering usually gets a lot of replies.
In this new framework, I am trying to separate everything into little chunks
I call "beads". The visual components are supposed to have a minimum of
three beads, one each for MVC, and the V is essentially the Skin.
Components don't assume they are on the Flash display list. Instead of
calling addChild, you call child.addToParent.
So, yes, you could write new view beads that create their visuals using
starling. I suppose we could rewire addToParent to do what you want.
I didn't explicitly design the new framework for starling. I still need
convincing that it truly makes a difference for the vast majority of
business applications. I still think your Flex apps are busy running AS code
or suffering from having too many display objects per component which I do
want to tackle in this new framework. Early versions of this new framework
are probably not going to support 3D effects and 3D rendering so I think I
have time before I have to really deal with it.
I did consider that the new framework would favor bitmaps over vectors, at
least in the early versions. I'm not planning support on the JS side for
vector graphics right away, so you are reduced to using bitmaps for many
more things, which I think most folks do in HTML/JS and which GPUs seem to
like more.
The prototype is checked in: FalconJS is in the falcon/trunk/compiler.js
folder. The latest ASJS framework is in asjs/branches/develop/framework,
and the example that uses it is in
asjs/branches/develop/examples/FlexJSTest_again.
On 1/18/13 11:04 AM, "Om" <bi...@gmail.com> wrote:
> On Fri, Jan 18, 2013 at 10:00 AM, Alex Harui <ah...@adobe.com> wrote:
>
>> That's why I've chosen a new
>> parallel framework: I've already got a prototype up and running, and I
>> would not be able to do that with the current Flex SDK. Hopefully the
>> patterns I am using the new framework are extensible enough to allow it to
>> grow up to match the old Flex SDK over time.
>>
>
> This sounds very interesting to me. I have been playing around with
> Starling and Stage3D to see how best to render Flex via the GPU. I've come
> to the conclusion that this would entail rewriting a lot of of existing
> Flex code. In your new framework, do you think it would be possible to
> switch from DisplayObject based rendering to GPU based rendering as needed?
> Did you consider this option when designing your new framework?
>
> Any chance we could see your prototype any time soon?
>
> Thanks,
> Om
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
Re: ASJS and Starling (was Re: [FalconJx] where I'm going to be)
Posted by Om <bi...@gmail.com>.
On Mon, Jan 21, 2013 at 8:46 PM, Alex Harui <ah...@adobe.com> wrote:
>
>
>
> On 1/21/13 5:21 PM, "Om" <bi...@gmail.com> wrote:
>
> > On Fri, Jan 18, 2013 at 11:49 AM, Alex Harui <ah...@adobe.com> wrote:
> >
> >> Changing subject because GPU rendering usually gets a lot of replies.
> >>
> >> In this new framework, I am trying to separate everything into little
> >> chunks
> >> I call "beads". The visual components are supposed to have a minimum of
> >> three beads, one each for MVC, and the V is essentially the Skin.
> >>
> >
> > I spent some time going through your new framework. First off, I think
> it
> > deserves to be called something else. The "JS" in "ASJS" implies that it
> > is a JS specific implementation of the framework. In reality it is not.
> Well, I called that to show that it is a parallel framework. That we build
> both AS and JS beads. But I don't care to much about what we end up
> calling
> it.
> > Second, it deserves its own wiki page.
> Well, I think there is one:
> https://cwiki.apache.org/confluence/display/FLEX/Alex%27s+FlexJS+Prototype
>
I meant a separate wiki page describing the framework alone. The
cross-compilation to JS could be in a separate page. Not a big deal, but I
thought the new framework needs to be its own thing.
> > The reason is: I see this as a clean way to start implementing a new
> Flex
> > framework. The effort that you, Michael.S and Erik have undertaken to
> make
> > it work in HTML/JS can work in parallel with a Starling/GPU based View
> for
> > the same new Flex framework.
> >
> >
> >>
> >> Components don't assume they are on the Flash display list. Instead of
> >> calling addChild, you call child.addToParent.
> >>
> >
> > This makes a lot of sense. Except that Starling's APIs tries to mimic
> the
> > current Flash Player's display list paradigm. I need to spend some time
> > trying to figure out how I can tie these things up. Any thoughts?
> Did you see the thread today where someone else proposed an alternative to
> Starling? Starling may not be the best way to get at stage3D/gpu. Any
> emulation of the display list is likely to cost more cycles than one tuned
> to the platform. Do we really need a display list at all? If not, then
> don't use one.
>
I believe you are talking about MadComponents? They still draw on the
display list, rasterize it and upload it as a texture to Stage3D. I am not
very well versed in MadComponents, but I will definitely give it a shot.
I believe that Starling makes things easier for us to work with as it
abstracts a lot of the Stage3D complexity. I am not ready to rule out
Starling yet.
Coupling this with the new Query Graphics Data API in FP 11.6, there is an
interesting possibility of being able to draw vector graphics directly via
the GPU (again by drawing on the display list first):
http://blog.bwhiting.co.uk/?p=423
> >
> >
> >>
> >> So, yes, you could write new view beads that create their visuals using
> >> starling. I suppose we could rewire addToParent to do what you want.
> >>
> >
> > This is the part that excites me most. I will start writing an
> > implementation of your framework with a Starling based view. I might
> have
> > to a new implementation of Application.as.
> In my view of the world, there will be many packages with different flavors
> of Applications, components and beads.
> >
> > Do you mind if I pollute the asjs directory with my code, or would you
> > prefer that I do it on my whiteboard?
> I think you can do it directly in the asjs directory if you organize the
> packages in a reasonable way.
>
Okay. I will propose something once we figure out the naming issue.
>
> >
> >
> >>
> >> I didn't explicitly design the new framework for starling.
> >
> >
> > I think that is a good thing. The more clearer the separation there is
> > between the rest of the framework and the render specific stuff, the
> better
> > for everyone.
> >
> >
> >> I still need convincing that it truly makes a difference for the vast
> >> majority of
> >> business applications. I still think your Flex apps are busy running AS
> >> code
> >> or suffering from having too many display objects per component which I
> do
> >> want to tackle in this new framework.
> >
> >
> > My take on this is: I have worked on so many data intensive applications
> > where performance goes for a toss when the framework is trying to draw
> too
> > many things on the screen.
> OK, but did you put in the profiler? Did [render] actually show up or is
> other code running instead?
>
I did not test the profiler with my work on the iPad (1 and 2). I will try
to put up a test harness and test it across hardware and devices. Yet
another thing on my todo list.
> > Utilizing the GPU (especially on mobile) would
> > definitely make a difference.
> Again, do you have empirical evidence? It makes sense for sprite sheets in
> a game, but I don't understand what kind of visualization you are doing in
> your business apps that is similar.
>
The app I worked was a web-to-print kind of an application. Basically
allowing the user to add a elements on a page (bitmaps, vector art, text,
filters, etc.) and allows the user to manipulate each element individually,
align, size etc. Imagine Adobe Indesign on the web and tablet. The
biggest pain point was when I selected a single element and simply moved it
across the screen. It was extremely sluggish. I solved this problem by
bringing the selected object to the top of the display list and rasterized
everything behind it. So it was basically just two objects on the screen.
This fix alone improved the app's performance by a magnitude.
>From what I have seen, MadComponents does something similar, except that
the rasters are rendered via the GPU. That is an approach I want to try as
well.
>
> > For legacy hardware, things would fallback
> > to to a software engine anyways, so what is the harm in trying this out?
> No harm, if this is your itch, you are welcome to scratch it, but I am all
> about expectation management. So if it were me I would use profiler data
> to
> set expectations. One of my goals of the new framework is to try to apply
> simple principles of just-in-time and on-demand so the SDK doesn't waste
> cycles for just-in-case stuff like it does now. That alone might give you
> the performance boost you are looking for.
>
Point taken. I will work on a test harness first.
But I also consider this as an opportunity to take advantage of the latest
features of the Flash Player and including (hopefully) whatever Flash
Player 12 and AS4 would throw at us.
> >
> >
> >
> >>
> >> The prototype is checked in: FalconJS is in the
> falcon/trunk/compiler.js
> >> folder. The latest ASJS framework is in
> asjs/branches/develop/framework,
> >> and the example that uses it is in
> >> asjs/branches/develop/examples/FlexJSTest_again.
> >>
> >>
> >>
> > As I said earlier, it would be fantastic if you could split the new
> > framework into separate directory and not throw it in along with ASJS.
> Does
> > that make sense?
> Well, you can argue for a different name for the folder, but its ability to
> have a parallel JS framework is highly important and one of the major
> design/implementation constraints, so I like the idea there is an as folder
> next to the js folder in SVN. If your work turns out to be just
> alternative
> skins, that can be managed in a separate package or folder. For now, I
> think you should just start sticking in code and see what we end up with
> then we can figure out a better organization later when we understand what
> we have.
>
>
Thanks,
Om
Re: ASJS and Starling (was Re: [FalconJx] where I'm going to be)
Posted by Om <bi...@gmail.com>.
On Tue, Jan 22, 2013 at 9:39 AM, Alex Harui <ah...@adobe.com> wrote:
> Erik,
>
> I think having a separate folder off root will make it hard to maintain the
> parallel-ism. That would be two different SVN projects to figure out how
> to
> release together, and two different checkins to keep things in sync.
>
> In my vision, the new framework does need to allow for alternative
> implementations like Om is doing, not all of which need to have an exact JS
> equivalent if an existing JS equivalent is sufficient.
>
> One way would be to add a third folder next to as and js. We could just
> call in "om" for now, or maybe "gpu".
>
> But as long as the files he adds doesn't mess up what we're doing, I don't
> think it should matter too much right now. We're all in experimenting
> mode.
>
>
Except that the name ASJS is misleading, the way it is currently set up.
I dont want this to cause confusion and prevent people from contributing to
this new framework because they are not interested in a JS specific
solution.
Either we rename ASJS to something else, or we split it up into two top
level projects. I am fine with either option.
Thanks,
Om
Re: ASJS and Starling (was Re: [FalconJx] where I'm going to be)
Posted by Om <bi...@gmail.com>.
On Tue, Jan 22, 2013 at 2:40 AM, Erik de Bruin <er...@ixsoftware.nl> wrote:
> Om,
>
> I see your point. Here's mine: Alex's new framework has an AS and a JS
> part. Currently projects build using his AS part are compiled with
> FalconJS to run in the browser using his JS framework. Alex has named
> his framework combo FlexJS. I think that name (FlexJS) should be
> revisited as that framework clearly has more uses than enabling JS
> output.
>
> You are 'only' interested in the AS part of FlexJS. My suggestion
> would be that you and Alex move the AS framework out of the asjs tree
> into it's own root *AlexFlex*. This leaves only JS frameworks (with
> the JS part of FlexJS chief among them) in 'asjs/../frameworks/js', so
> these JS frameworks could move up one level.
>
> The new situation should look something like this (hoping it isn't
> wrapped to pieces by the various email clients):
>
> root
> |
> - asjs
> |
> - branches
> |
> - develop
> |
> - examples
> |
> - frameworks
> |
> - *FlexJS* (the JS part)
> |
> - VanillaSDK
> |
> - publisher
> - *AlexFlex*
> |
> - branches
> |
> - develop
> |
> - frameworks
> |
> - *FlexJS* (the AS part)
> |
> - *OM_GPU_MAGIC*
>
>
> That way, everything that has to do with AS -> JS cross compilation
> can stay in 'asjs' (which is a fitting name), and anything that has to
> do with Alex's new AS framework goes into the new location.
>
> Makes sense?
>
> EdB
>
>
>
> > http://svn.apache.org/viewvc/flex/*asjs*/branches/develop/frameworks/as/
> >
> http://svn.apache.org/viewvc/flex/*asjs*/branches/develop/frameworks/js/FlexJS/
> >
> http://svn.apache.org/viewvc/flex/*asjs*/branches/develop/frameworks/js/VanillaSDK/
> > etc.
> >
> > lets make it (replace *AlexFlex *with whatever codename you want to):
> >
> >
> http://svn.apache.org/viewvc/flex/*AlexFlex*/branches/develop/frameworks/as/
> >
> http://svn.apache.org/viewvc/flex/*AlexFlex*/branches/develop/frameworks/js/FlexJS/
> >
> http://svn.apache.org/viewvc/flex/*AlexFlex*/branches/develop/frameworks/js/VanillaSDK/
> > etc.
> >
> > This way, I can go in and add something like:
> >
> http://svn.apache.org/viewvc/flex/*AlexFlex*/branches/develop/frameworks/as/src/org/apache/flex/stage3d/
> >
> > alongside
> >
> >
> http://svn.apache.org/viewvc/flex/*AlexFlex*/branches/develop/frameworks/as/src/org/apache/flex/html/
>
>
> --
> Ix Multimedia Software
>
> Jan Luykenstraat 27
> 3521 VB Utrecht
>
> T. 06-51952295
> I. www.ixsoftware.nl
>
Re: ASJS and Starling (was Re: [FalconJx] where I'm going to be)
Posted by Alex Harui <ah...@adobe.com>.
Erik,
I think having a separate folder off root will make it hard to maintain the
parallel-ism. That would be two different SVN projects to figure out how to
release together, and two different checkins to keep things in sync.
In my vision, the new framework does need to allow for alternative
implementations like Om is doing, not all of which need to have an exact JS
equivalent if an existing JS equivalent is sufficient.
One way would be to add a third folder next to as and js. We could just
call in "om" for now, or maybe "gpu".
But as long as the files he adds doesn't mess up what we're doing, I don't
think it should matter too much right now. We're all in experimenting mode.
On 1/22/13 2:40 AM, "Erik de Bruin" <er...@ixsoftware.nl> wrote:
> Om,
>
> I see your point. Here's mine: Alex's new framework has an AS and a JS
> part. Currently projects build using his AS part are compiled with
> FalconJS to run in the browser using his JS framework. Alex has named
> his framework combo FlexJS. I think that name (FlexJS) should be
> revisited as that framework clearly has more uses than enabling JS
> output.
>
> You are 'only' interested in the AS part of FlexJS. My suggestion
> would be that you and Alex move the AS framework out of the asjs tree
> into it's own root *AlexFlex*. This leaves only JS frameworks (with
> the JS part of FlexJS chief among them) in 'asjs/../frameworks/js', so
> these JS frameworks could move up one level.
>
> The new situation should look something like this (hoping it isn't
> wrapped to pieces by the various email clients):
>
> root
> |
> - asjs
> |
> - branches
> |
> - develop
> |
> - examples
> |
> - frameworks
> |
> - *FlexJS* (the JS part)
> |
> - VanillaSDK
> |
> - publisher
> - *AlexFlex*
> |
> - branches
> |
> - develop
> |
> - frameworks
> |
> - *FlexJS* (the AS part)
> |
> - *OM_GPU_MAGIC*
>
>
> That way, everything that has to do with AS -> JS cross compilation
> can stay in 'asjs' (which is a fitting name), and anything that has to
> do with Alex's new AS framework goes into the new location.
>
> Makes sense?
>
> EdB
>
>
>
>> http://svn.apache.org/viewvc/flex/*asjs*/branches/develop/frameworks/as/
>> http://svn.apache.org/viewvc/flex/*asjs*/branches/develop/frameworks/js/FlexJ
>> S/
>> http://svn.apache.org/viewvc/flex/*asjs*/branches/develop/frameworks/js/Vanil
>> laSDK/
>> etc.
>>
>> lets make it (replace *AlexFlex *with whatever codename you want to):
>>
>> http://svn.apache.org/viewvc/flex/*AlexFlex*/branches/develop/frameworks/as/
>> http://svn.apache.org/viewvc/flex/*AlexFlex*/branches/develop/frameworks/js/F
>> lexJS/
>> http://svn.apache.org/viewvc/flex/*AlexFlex*/branches/develop/frameworks/js/V
>> anillaSDK/
>> etc.
>>
>> This way, I can go in and add something like:
>> http://svn.apache.org/viewvc/flex/*AlexFlex*/branches/develop/frameworks/as/s
>> rc/org/apache/flex/stage3d/
>>
>> alongside
>>
>> http://svn.apache.org/viewvc/flex/*AlexFlex*/branches/develop/frameworks/as/s
>> rc/org/apache/flex/html/
>
>
> --
> Ix Multimedia Software
>
> Jan Luykenstraat 27
> 3521 VB Utrecht
>
> T. 06-51952295
> I. www.ixsoftware.nl
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
Re: ASJS and Starling (was Re: [FalconJx] where I'm going to be)
Posted by Erik de Bruin <er...@ixsoftware.nl>.
Om,
I see your point. Here's mine: Alex's new framework has an AS and a JS
part. Currently projects build using his AS part are compiled with
FalconJS to run in the browser using his JS framework. Alex has named
his framework combo FlexJS. I think that name (FlexJS) should be
revisited as that framework clearly has more uses than enabling JS
output.
You are 'only' interested in the AS part of FlexJS. My suggestion
would be that you and Alex move the AS framework out of the asjs tree
into it's own root *AlexFlex*. This leaves only JS frameworks (with
the JS part of FlexJS chief among them) in 'asjs/../frameworks/js', so
these JS frameworks could move up one level.
The new situation should look something like this (hoping it isn't
wrapped to pieces by the various email clients):
root
|
- asjs
|
- branches
|
- develop
|
- examples
|
- frameworks
|
- *FlexJS* (the JS part)
|
- VanillaSDK
|
- publisher
- *AlexFlex*
|
- branches
|
- develop
|
- frameworks
|
- *FlexJS* (the AS part)
|
- *OM_GPU_MAGIC*
That way, everything that has to do with AS -> JS cross compilation
can stay in 'asjs' (which is a fitting name), and anything that has to
do with Alex's new AS framework goes into the new location.
Makes sense?
EdB
> http://svn.apache.org/viewvc/flex/*asjs*/branches/develop/frameworks/as/
> http://svn.apache.org/viewvc/flex/*asjs*/branches/develop/frameworks/js/FlexJS/
> http://svn.apache.org/viewvc/flex/*asjs*/branches/develop/frameworks/js/VanillaSDK/
> etc.
>
> lets make it (replace *AlexFlex *with whatever codename you want to):
>
> http://svn.apache.org/viewvc/flex/*AlexFlex*/branches/develop/frameworks/as/
> http://svn.apache.org/viewvc/flex/*AlexFlex*/branches/develop/frameworks/js/FlexJS/
> http://svn.apache.org/viewvc/flex/*AlexFlex*/branches/develop/frameworks/js/VanillaSDK/
> etc.
>
> This way, I can go in and add something like:
> http://svn.apache.org/viewvc/flex/*AlexFlex*/branches/develop/frameworks/as/src/org/apache/flex/stage3d/
>
> alongside
>
> http://svn.apache.org/viewvc/flex/*AlexFlex*/branches/develop/frameworks/as/src/org/apache/flex/html/
--
Ix Multimedia Software
Jan Luykenstraat 27
3521 VB Utrecht
T. 06-51952295
I. www.ixsoftware.nl
Re: ASJS and Starling (was Re: [FalconJx] where I'm going to be)
Posted by Om <bi...@gmail.com>.
On Mon, Jan 21, 2013 at 11:02 PM, Erik de Bruin <er...@ixsoftware.nl> wrote:
> Hi,
>
> >> I spent some time going through your new framework. First off, I think
> it
> >> deserves to be called something else. The "JS" in "ASJS" implies that
> it
> >> is a JS specific implementation of the framework. In reality it is not.
> > Well, I called that to show that it is a parallel framework. That we
> build
> > both AS and JS beads. But I don't care to much about what we end up
> calling
> > it.
>
> Well, I do care. There are 2 naming conventions I think are working
> well right now: the intended use of a framework decides the first:
> ASJS stands for Actionscript to JavaScript, exactly what the
> frameworks and tools in there do.
There is a brand new framework in there that has nothing to do with JS
[1]. In fact, Alex has envisioned this new framework in a way that it does
not know where it is going to be run on. My proposal is to have a
directory structure that clearly separates the concerns.
> The second is the approach taken
> when going from AS to JS: first there is FlexJS, Alex's set of bottom
> up, start from scratch frameworks (one for AS and one for JS), and
> then there is VanillaSDK, my attempt at a top down, use the Flex SDK
> and write a complimentary JS framework approach.
>
> ASJS is also the home of the Publisher I'm writing, which will take
> either framework (FlexJS and VanillaSDK) and use it and it's
> dependencies to build an AS/MXML project into a HTML/JS project, again
> AS -> JS.
>
> I don't mind renaming/rebranding things, especially is something is
> gained by doing so (even if it's only better marketing), but we should
> take care not to end up with a too generic naming convention just
> trying to fit too many projects under one roof.
>
I agree with everything you are saying. But please hear me out. This is
what I am proposing: Instead of it being:
http://svn.apache.org/viewvc/flex/*asjs*/branches/develop/frameworks/as/
http://svn.apache.org/viewvc/flex/*asjs*
/branches/develop/frameworks/js/FlexJS/
http://svn.apache.org/viewvc/flex/*asjs*
/branches/develop/frameworks/js/VanillaSDK/
etc.
lets make it (replace *AlexFlex *with whatever codename you want to):
http://svn.apache.org/viewvc/flex/*AlexFlex*/branches/develop/frameworks/as/
http://svn.apache.org/viewvc/flex/*AlexFlex*
/branches/develop/frameworks/js/FlexJS/
http://svn.apache.org/viewvc/flex/*AlexFlex*
/branches/develop/frameworks/js/VanillaSDK/
etc.
This way, I can go in and add something like:
http://svn.apache.org/viewvc/flex/*AlexFlex*
/branches/develop/frameworks/as/src/org/apache/flex/stage3d/
alongside
http://svn.apache.org/viewvc/flex/*AlexFlex*
/branches/develop/frameworks/as/src/org/apache/flex/html/
Do you see where I am going with this? My goal (if a bit naive) is to tag
along with this new framework and explore how best we can start rendering
stuff using the GPU. Having a source tree with the term "asjs" and working
on Flash player specific stuff - that can never be replicated in JS or
HTML5 sounds like a bad idea to me. Hence the request.
If you have an alternative to what I am trying to achieve, I am all ears.
Thanks,
Om
> EdB
>
>
>
[1] http://svn.apache.org/viewvc/flex/asjs/branches/develop/frameworks/as/
Re: ASJS and Starling (was Re: [FalconJx] where I'm going to be)
Posted by Erik de Bruin <er...@ixsoftware.nl>.
Hi,
>> I spent some time going through your new framework. First off, I think it
>> deserves to be called something else. The "JS" in "ASJS" implies that it
>> is a JS specific implementation of the framework. In reality it is not.
> Well, I called that to show that it is a parallel framework. That we build
> both AS and JS beads. But I don't care to much about what we end up calling
> it.
Well, I do care. There are 2 naming conventions I think are working
well right now: the intended use of a framework decides the first:
ASJS stands for Actionscript to JavaScript, exactly what the
frameworks and tools in there do. The second is the approach taken
when going from AS to JS: first there is FlexJS, Alex's set of bottom
up, start from scratch frameworks (one for AS and one for JS), and
then there is VanillaSDK, my attempt at a top down, use the Flex SDK
and write a complimentary JS framework approach.
ASJS is also the home of the Publisher I'm writing, which will take
either framework (FlexJS and VanillaSDK) and use it and it's
dependencies to build an AS/MXML project into a HTML/JS project, again
AS -> JS.
I don't mind renaming/rebranding things, especially is something is
gained by doing so (even if it's only better marketing), but we should
take care not to end up with a too generic naming convention just
trying to fit too many projects under one roof.
EdB
--
Ix Multimedia Software
Jan Luykenstraat 27
3521 VB Utrecht
T. 06-51952295
I. www.ixsoftware.nl
RE: ASJS and Starling (was Re: [FalconJx] where I'm going to be)
Posted by Kessler CTR Mark J <ma...@usmc.mil>.
Well Firefox, Chrome, Safari(disabled by default), Opera, few mobile ones support it. IE only supports it atm with a plugin. However it is pretty much a deal breaker to design the end state twice.
But if you want an easy to read does my browser support WebGL type page.. try this. Yay/nay lol.
http://www.doesmybrowsersupportwebgl.com/
-Mark
-----Original Message-----
From: Kevin Newman [mailto:CaptainN@unFocus.com]
Sent: Tuesday, January 22, 2013 10:37
To: dev@flex.apache.org
Subject: Re: ASJS and Starling (was Re: [FalconJx] where I'm going to be)
WebGL isn't supported by IE (and various flavors of WebKit and maybe not
Opera either), so you'd have to do two implementations, one in WebGL,
and a fallback in Canvas (which in IE is GPU accelerated).
Kevin N.
On 1/22/13 7:26 AM, Kessler CTR Mark J wrote:
> I was going to recommend trying a WebGL for GPU rendering. However, while most browsers support it. Microsoft has not yet jumped on board. It does use the HTML5 Canvas to render on.
>
> I didn't even remember it existed really until I read an article about a game from Mozilla demo studio called BananaBread. It was a "3D first person shooter game compiled to JS+WebGL". The part that caught my eye was the "Compiled into JS+WebGL".
>
> https://developer.mozilla.org/en-US/demos/detail/bananabread
>
>
> Are there any other well adopted standards similar to WebGL?
>
>
> -Mark
Re: ASJS and Starling (was Re: [FalconJx] where I'm going to be)
Posted by Kevin Newman <Ca...@unFocus.com>.
WebGL isn't supported by IE (and various flavors of WebKit and maybe not
Opera either), so you'd have to do two implementations, one in WebGL,
and a fallback in Canvas (which in IE is GPU accelerated).
Kevin N.
On 1/22/13 7:26 AM, Kessler CTR Mark J wrote:
> I was going to recommend trying a WebGL for GPU rendering. However, while most browsers support it. Microsoft has not yet jumped on board. It does use the HTML5 Canvas to render on.
>
> I didn't even remember it existed really until I read an article about a game from Mozilla demo studio called BananaBread. It was a "3D first person shooter game compiled to JS+WebGL". The part that caught my eye was the "Compiled into JS+WebGL".
>
> https://developer.mozilla.org/en-US/demos/detail/bananabread
>
>
> Are there any other well adopted standards similar to WebGL?
>
>
> -Mark
RE: ASJS and Starling (was Re: [FalconJx] where I'm going to be)
Posted by Kessler CTR Mark J <ma...@usmc.mil>.
I was going to recommend trying a WebGL for GPU rendering. However, while most browsers support it. Microsoft has not yet jumped on board. It does use the HTML5 Canvas to render on.
I didn't even remember it existed really until I read an article about a game from Mozilla demo studio called BananaBread. It was a "3D first person shooter game compiled to JS+WebGL". The part that caught my eye was the "Compiled into JS+WebGL".
https://developer.mozilla.org/en-US/demos/detail/bananabread
Are there any other well adopted standards similar to WebGL?
-Mark
-----Original Message-----
From: omuppi1@gmail.com [mailto:omuppi1@gmail.com] On Behalf Of Om
Sent: Monday, January 21, 2013 20:22
To: dev@flex.apache.org
Subject: Re: ASJS and Starling (was Re: [FalconJx] where I'm going to be)
On Fri, Jan 18, 2013 at 11:49 AM, Alex Harui <ah...@adobe.com> wrote:
> Changing subject because GPU rendering usually gets a lot of replies.
>
> In this new framework, I am trying to separate everything into little
> chunks
> I call "beads". The visual components are supposed to have a minimum of
> three beads, one each for MVC, and the V is essentially the Skin.
>
I spent some time going through your new framework. First off, I think it
deserves to be called something else. The "JS" in "ASJS" implies that it
is a JS specific implementation of the framework. In reality it is not.
Second, it deserves its own wiki page.
The reason is: I see this as a clean way to start implementing a new Flex
framework. The effort that you, Michael.S and Erik have undertaken to make
it work in HTML/JS can work in parallel with a Starling/GPU based View for
the same new Flex framework.
>
> Components don't assume they are on the Flash display list. Instead of
> calling addChild, you call child.addToParent.
>
This makes a lot of sense. Except that Starling's APIs tries to mimic the
current Flash Player's display list paradigm. I need to spend some time
trying to figure out how I can tie these things up. Any thoughts?
>
> So, yes, you could write new view beads that create their visuals using
> starling. I suppose we could rewire addToParent to do what you want.
>
This is the part that excites me most. I will start writing an
implementation of your framework with a Starling based view. I might have
to a new implementation of Application.as.
Do you mind if I pollute the asjs directory with my code, or would you
prefer that I do it on my whiteboard?
>
> I didn't explicitly design the new framework for starling.
I think that is a good thing. The more clearer the separation there is
between the rest of the framework and the render specific stuff, the better
for everyone.
> I still need convincing that it truly makes a difference for the vast
> majority of
> business applications. I still think your Flex apps are busy running AS
> code
> or suffering from having too many display objects per component which I do
> want to tackle in this new framework.
My take on this is: I have worked on so many data intensive applications
where performance goes for a toss when the framework is trying to draw too
many things on the screen. Utilizing the GPU (especially on mobile) would
definitely make a difference. For legacy hardware, things would fallback
to to a software engine anyways, so what is the harm in trying this out?
> I did consider that the new framework would favor bitmaps over vectors, at
least in the early versions. I'm not planning support on the JS side for
> vector graphics right away, so you are reduced to using bitmaps for many
> more things, which I think most folks do in HTML/JS and which GPUs seem to
> like more.
>
Again, this is a good thing. In my experiments with Flex on mobile
devices, rastering displayobjects and removing them off the display yielded
so much better performance. Imagine if everything we had this kind of
support in the framework itself.
>
> The prototype is checked in: FalconJS is in the falcon/trunk/compiler.js
> folder. The latest ASJS framework is in asjs/branches/develop/framework,
> and the example that uses it is in
> asjs/branches/develop/examples/FlexJSTest_again.
>
>
>
As I said earlier, it would be fantastic if you could split the new
framework into separate directory and not throw it in along with ASJS. Does
that make sense?
Thanks,
Om
> On 1/18/13 11:04 AM, "Om" <bi...@gmail.com> wrote:
>
> > On Fri, Jan 18, 2013 at 10:00 AM, Alex Harui <ah...@adobe.com> wrote:
> >
> >> That's why I've chosen a new
> >> parallel framework: I've already got a prototype up and running, and I
> >> would not be able to do that with the current Flex SDK. Hopefully the
> >> patterns I am using the new framework are extensible enough to allow it
> to
> >> grow up to match the old Flex SDK over time.
> >>
> >
> > This sounds very interesting to me. I have been playing around with
> > Starling and Stage3D to see how best to render Flex via the GPU. I've
> come
> > to the conclusion that this would entail rewriting a lot of of existing
> > Flex code. In your new framework, do you think it would be possible to
> > switch from DisplayObject based rendering to GPU based rendering as
> needed?
> > Did you consider this option when designing your new framework?
> >
> > Any chance we could see your prototype any time soon?
> >
> > Thanks,
> > Om
>
> --
> Alex Harui
> Flex SDK Team
> Adobe Systems, Inc.
> http://blogs.adobe.com/aharui
>
>
Re: ASJS and Starling (was Re: [FalconJx] where I'm going to be)
Posted by Frank Wienberg <fr...@jangaroo.net>.
On Tue, Jan 22, 2013 at 5:34 PM, Michael Schmalle
<ap...@teotigraphix.com>wrote:
> This is how Android works to, you draw to Bitmaps.
>
> It has a "display list" for layout like algorithms but the Canvas is
> passed around to be drawn on.
>
>
Isn't that similar to a Flash Stage with cacheAsBitmap=true?
At least this is how I implemented "cacheAsBitmap" in JooFlash (see
other thread).
Re: ASJS and Starling (was Re: [FalconJx] where I'm going to be)
Posted by Michael Schmalle <ap...@teotigraphix.com>.
This is how Android works to, you draw to Bitmaps.
It has a "display list" for layout like algorithms but the Canvas is
passed around to be drawn on.
Mike
Quoting Kevin Newman <Ca...@unFocus.com>:
> Flex could do something more like they do on iOS. They can build an
> entire layout as one bitmap, but to get parts that can change or
> animate, they use layer-backing. So they only create a new quad for
> the parts they need to. This seems to be a better strategy on mobile
> than a deep display list, where everything gets it's own BitmapData
> and quad.
>
> Kevin N.
>
>
> On 1/21/13 11:46 PM, Alex Harui wrote:
>> Did you see the thread today where someone else proposed an alternative to
>> Starling? Starling may not be the best way to get at stage3D/gpu. Any
>> emulation of the display list is likely to cost more cycles than one tuned
>> to the platform. Do we really need a display list at all? If not, then
>> don't use one.
>
>
--
Michael Schmalle - Teoti Graphix, LLC
http://www.teotigraphix.com
http://blog.teotigraphix.com
Re: ASJS and Starling (was Re: [FalconJx] where I'm going to be)
Posted by Kevin Newman <Ca...@unFocus.com>.
Flex could do something more like they do on iOS. They can build an
entire layout as one bitmap, but to get parts that can change or
animate, they use layer-backing. So they only create a new quad for the
parts they need to. This seems to be a better strategy on mobile than a
deep display list, where everything gets it's own BitmapData and quad.
Kevin N.
On 1/21/13 11:46 PM, Alex Harui wrote:
> Did you see the thread today where someone else proposed an alternative to
> Starling? Starling may not be the best way to get at stage3D/gpu. Any
> emulation of the display list is likely to cost more cycles than one tuned
> to the platform. Do we really need a display list at all? If not, then
> don't use one.
Re: ASJS and Starling (was Re: [FalconJx] where I'm going to be)
Posted by Alex Harui <ah...@adobe.com>.
On 1/21/13 5:21 PM, "Om" <bi...@gmail.com> wrote:
> On Fri, Jan 18, 2013 at 11:49 AM, Alex Harui <ah...@adobe.com> wrote:
>
>> Changing subject because GPU rendering usually gets a lot of replies.
>>
>> In this new framework, I am trying to separate everything into little
>> chunks
>> I call "beads". The visual components are supposed to have a minimum of
>> three beads, one each for MVC, and the V is essentially the Skin.
>>
>
> I spent some time going through your new framework. First off, I think it
> deserves to be called something else. The "JS" in "ASJS" implies that it
> is a JS specific implementation of the framework. In reality it is not.
Well, I called that to show that it is a parallel framework. That we build
both AS and JS beads. But I don't care to much about what we end up calling
it.
> Second, it deserves its own wiki page.
Well, I think there is one:
https://cwiki.apache.org/confluence/display/FLEX/Alex%27s+FlexJS+Prototype
> The reason is: I see this as a clean way to start implementing a new Flex
> framework. The effort that you, Michael.S and Erik have undertaken to make
> it work in HTML/JS can work in parallel with a Starling/GPU based View for
> the same new Flex framework.
>
>
>>
>> Components don't assume they are on the Flash display list. Instead of
>> calling addChild, you call child.addToParent.
>>
>
> This makes a lot of sense. Except that Starling's APIs tries to mimic the
> current Flash Player's display list paradigm. I need to spend some time
> trying to figure out how I can tie these things up. Any thoughts?
Did you see the thread today where someone else proposed an alternative to
Starling? Starling may not be the best way to get at stage3D/gpu. Any
emulation of the display list is likely to cost more cycles than one tuned
to the platform. Do we really need a display list at all? If not, then
don't use one.
>
>
>>
>> So, yes, you could write new view beads that create their visuals using
>> starling. I suppose we could rewire addToParent to do what you want.
>>
>
> This is the part that excites me most. I will start writing an
> implementation of your framework with a Starling based view. I might have
> to a new implementation of Application.as.
In my view of the world, there will be many packages with different flavors
of Applications, components and beads.
>
> Do you mind if I pollute the asjs directory with my code, or would you
> prefer that I do it on my whiteboard?
I think you can do it directly in the asjs directory if you organize the
packages in a reasonable way.
>
>
>>
>> I didn't explicitly design the new framework for starling.
>
>
> I think that is a good thing. The more clearer the separation there is
> between the rest of the framework and the render specific stuff, the better
> for everyone.
>
>
>> I still need convincing that it truly makes a difference for the vast
>> majority of
>> business applications. I still think your Flex apps are busy running AS
>> code
>> or suffering from having too many display objects per component which I do
>> want to tackle in this new framework.
>
>
> My take on this is: I have worked on so many data intensive applications
> where performance goes for a toss when the framework is trying to draw too
> many things on the screen.
OK, but did you put in the profiler? Did [render] actually show up or is
other code running instead?
> Utilizing the GPU (especially on mobile) would
> definitely make a difference.
Again, do you have empirical evidence? It makes sense for sprite sheets in
a game, but I don't understand what kind of visualization you are doing in
your business apps that is similar.
> For legacy hardware, things would fallback
> to to a software engine anyways, so what is the harm in trying this out?
No harm, if this is your itch, you are welcome to scratch it, but I am all
about expectation management. So if it were me I would use profiler data to
set expectations. One of my goals of the new framework is to try to apply
simple principles of just-in-time and on-demand so the SDK doesn't waste
cycles for just-in-case stuff like it does now. That alone might give you
the performance boost you are looking for.
>
>
>
>>
>> The prototype is checked in: FalconJS is in the falcon/trunk/compiler.js
>> folder. The latest ASJS framework is in asjs/branches/develop/framework,
>> and the example that uses it is in
>> asjs/branches/develop/examples/FlexJSTest_again.
>>
>>
>>
> As I said earlier, it would be fantastic if you could split the new
> framework into separate directory and not throw it in along with ASJS. Does
> that make sense?
Well, you can argue for a different name for the folder, but its ability to
have a parallel JS framework is highly important and one of the major
design/implementation constraints, so I like the idea there is an as folder
next to the js folder in SVN. If your work turns out to be just alternative
skins, that can be managed in a separate package or folder. For now, I
think you should just start sticking in code and see what we end up with
then we can figure out a better organization later when we understand what
we have.
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
Re: ASJS and Starling (was Re: [FalconJx] where I'm going to be)
Posted by Om <bi...@gmail.com>.
On Fri, Jan 18, 2013 at 11:49 AM, Alex Harui <ah...@adobe.com> wrote:
> Changing subject because GPU rendering usually gets a lot of replies.
>
> In this new framework, I am trying to separate everything into little
> chunks
> I call "beads". The visual components are supposed to have a minimum of
> three beads, one each for MVC, and the V is essentially the Skin.
>
I spent some time going through your new framework. First off, I think it
deserves to be called something else. The "JS" in "ASJS" implies that it
is a JS specific implementation of the framework. In reality it is not.
Second, it deserves its own wiki page.
The reason is: I see this as a clean way to start implementing a new Flex
framework. The effort that you, Michael.S and Erik have undertaken to make
it work in HTML/JS can work in parallel with a Starling/GPU based View for
the same new Flex framework.
>
> Components don't assume they are on the Flash display list. Instead of
> calling addChild, you call child.addToParent.
>
This makes a lot of sense. Except that Starling's APIs tries to mimic the
current Flash Player's display list paradigm. I need to spend some time
trying to figure out how I can tie these things up. Any thoughts?
>
> So, yes, you could write new view beads that create their visuals using
> starling. I suppose we could rewire addToParent to do what you want.
>
This is the part that excites me most. I will start writing an
implementation of your framework with a Starling based view. I might have
to a new implementation of Application.as.
Do you mind if I pollute the asjs directory with my code, or would you
prefer that I do it on my whiteboard?
>
> I didn't explicitly design the new framework for starling.
I think that is a good thing. The more clearer the separation there is
between the rest of the framework and the render specific stuff, the better
for everyone.
> I still need convincing that it truly makes a difference for the vast
> majority of
> business applications. I still think your Flex apps are busy running AS
> code
> or suffering from having too many display objects per component which I do
> want to tackle in this new framework.
My take on this is: I have worked on so many data intensive applications
where performance goes for a toss when the framework is trying to draw too
many things on the screen. Utilizing the GPU (especially on mobile) would
definitely make a difference. For legacy hardware, things would fallback
to to a software engine anyways, so what is the harm in trying this out?
> I did consider that the new framework would favor bitmaps over vectors, at
least in the early versions. I'm not planning support on the JS side for
> vector graphics right away, so you are reduced to using bitmaps for many
> more things, which I think most folks do in HTML/JS and which GPUs seem to
> like more.
>
Again, this is a good thing. In my experiments with Flex on mobile
devices, rastering displayobjects and removing them off the display yielded
so much better performance. Imagine if everything we had this kind of
support in the framework itself.
>
> The prototype is checked in: FalconJS is in the falcon/trunk/compiler.js
> folder. The latest ASJS framework is in asjs/branches/develop/framework,
> and the example that uses it is in
> asjs/branches/develop/examples/FlexJSTest_again.
>
>
>
As I said earlier, it would be fantastic if you could split the new
framework into separate directory and not throw it in along with ASJS. Does
that make sense?
Thanks,
Om
> On 1/18/13 11:04 AM, "Om" <bi...@gmail.com> wrote:
>
> > On Fri, Jan 18, 2013 at 10:00 AM, Alex Harui <ah...@adobe.com> wrote:
> >
> >> That's why I've chosen a new
> >> parallel framework: I've already got a prototype up and running, and I
> >> would not be able to do that with the current Flex SDK. Hopefully the
> >> patterns I am using the new framework are extensible enough to allow it
> to
> >> grow up to match the old Flex SDK over time.
> >>
> >
> > This sounds very interesting to me. I have been playing around with
> > Starling and Stage3D to see how best to render Flex via the GPU. I've
> come
> > to the conclusion that this would entail rewriting a lot of of existing
> > Flex code. In your new framework, do you think it would be possible to
> > switch from DisplayObject based rendering to GPU based rendering as
> needed?
> > Did you consider this option when designing your new framework?
> >
> > Any chance we could see your prototype any time soon?
> >
> > Thanks,
> > Om
>
> --
> Alex Harui
> Flex SDK Team
> Adobe Systems, Inc.
> http://blogs.adobe.com/aharui
>
>
Re: ASJS and Starling (was Re: [FalconJx] where I'm going to be)
Posted by Jonathan Campos <jo...@gmail.com>.
Very cool interesting work Alex. Going to need to stop and check this out.
I've been using feathers recently for a few display object heavy mobile
apps and it has worked well. Would like to get back some parts from flex.
When I was playing with making a starling version of flex I felt the need
for a new way for add child also. So yea... Long story short definitely
understand and like where you are going.
On Jan 18, 2013 1:49 PM, "Alex Harui" <ah...@adobe.com> wrote:
> Changing subject because GPU rendering usually gets a lot of replies.
>
> In this new framework, I am trying to separate everything into little
> chunks
> I call "beads". The visual components are supposed to have a minimum of
> three beads, one each for MVC, and the V is essentially the Skin.
>
> Components don't assume they are on the Flash display list. Instead of
> calling addChild, you call child.addToParent.
>
> So, yes, you could write new view beads that create their visuals using
> starling. I suppose we could rewire addToParent to do what you want.
>
> I didn't explicitly design the new framework for starling. I still need
> convincing that it truly makes a difference for the vast majority of
> business applications. I still think your Flex apps are busy running AS
> code
> or suffering from having too many display objects per component which I do
> want to tackle in this new framework. Early versions of this new framework
> are probably not going to support 3D effects and 3D rendering so I think I
> have time before I have to really deal with it.
>
> I did consider that the new framework would favor bitmaps over vectors, at
> least in the early versions. I'm not planning support on the JS side for
> vector graphics right away, so you are reduced to using bitmaps for many
> more things, which I think most folks do in HTML/JS and which GPUs seem to
> like more.
>
> The prototype is checked in: FalconJS is in the falcon/trunk/compiler.js
> folder. The latest ASJS framework is in asjs/branches/develop/framework,
> and the example that uses it is in
> asjs/branches/develop/examples/FlexJSTest_again.
>
>
> On 1/18/13 11:04 AM, "Om" <bi...@gmail.com> wrote:
>
> > On Fri, Jan 18, 2013 at 10:00 AM, Alex Harui <ah...@adobe.com> wrote:
> >
> >> That's why I've chosen a new
> >> parallel framework: I've already got a prototype up and running, and I
> >> would not be able to do that with the current Flex SDK. Hopefully the
> >> patterns I am using the new framework are extensible enough to allow it
> to
> >> grow up to match the old Flex SDK over time.
> >>
> >
> > This sounds very interesting to me. I have been playing around with
> > Starling and Stage3D to see how best to render Flex via the GPU. I've
> come
> > to the conclusion that this would entail rewriting a lot of of existing
> > Flex code. In your new framework, do you think it would be possible to
> > switch from DisplayObject based rendering to GPU based rendering as
> needed?
> > Did you consider this option when designing your new framework?
> >
> > Any chance we could see your prototype any time soon?
> >
> > Thanks,
> > Om
>
> --
> Alex Harui
> Flex SDK Team
> Adobe Systems, Inc.
> http://blogs.adobe.com/aharui
>
>