Re: ASJS and Starling (was Re: [FalconJx] where I'm going to be)
On Mon, Jan 21, 2013 at 11:02 PM, Erik de Bruin e...@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)
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)
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: omup...@gmail.com [mailto:omup...@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 aha...@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 bigosma...@gmail.com wrote: On Fri, Jan 18, 2013 at 10:00 AM, Alex Harui aha...@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
RE: ASJS and Starling (was Re: [FalconJx] where I'm going to be)
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:capta...@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)
On Tue, Jan 22, 2013 at 2:40 AM, Erik de Bruin e...@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)
On 1/21/13 5:21 PM, Om bigosma...@gmail.com wrote: On Fri, Jan 18, 2013 at 11:49 AM, Alex Harui aha...@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
Re: ASJS and Starling (was Re: [FalconJx] where I'm going to be)
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
