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 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 > >
