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