On Mon, Jan 21, 2013 at 8:46 PM, Alex Harui <aha...@adobe.com> wrote:
> > > > 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 > 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
