heh - nothing to do with this thread, but as I glanced to my inbox, I thought the from field read, "Kevin Mitnick" had to make a double take. Couldn't think of any really valid reason why Mitnick would've been sending an email my way :P anyway ... don't let me interrupt the thread :D
On Fri, Jul 19, 2013 at 3:08 PM, Nick Collins <ndcoll...@gmail.com> wrote: > Not holding my breath for that one, Kevin... though I agree it would be > very cool! > > > On Fri, Jul 19, 2013 at 3:57 PM, Kevin Newman <capta...@unfocus.com> > wrote: > > > The higher level Flex Framework doesn't really need to know about all > > the AGAL, texture stuff, etc. It's possible (as Gnome2D has shown) to > > basically just make a blitting surface, and treat it like a BitmapData > > object that has high initial latency, with screaming runtime blitting, > > for rendering (as an extreme over simplification). > > > > The trick with the GPU is the lack of shared address space between CPU > > and GPU, which creates a huge bottleneck for moving image data from CPU > > to GPU. That's the primary pain point. Anyone implementing a high level > > API on GPU, mostly needs to target that pain point - keep GPU uploads > > and invalidation low, and you'll be fine (as long as your GPU code is > > stable, handles batching well, and doesn't change the GPU state too > much). > > > > On iOS, they use a metaphor of "layer backing" to help keep the pain > > point clear as they are designing, and communicating that to users of > > the their GPU powered APIs. WebKit uses that in some docs too, though > > it's less clear when you are activating layer backing, and Adobe tried > > to communicate that when they were doing GPU-Blend (something marked > > with cacheAsBitmapMatrix became "layer backed") with earlier builds of > > PFI, though they eventually switched to a GPU tessellation method of > > rendering. > > > > Related: What's really more exciting than I think the lack of buzz > > indicates, is AMD's new shared address space for CPU and GPU (in the > > chip shipping in both XBox One and PS4). That's going to completely > > remove this primary bottleneck, and make GPU programming a first class > > citizen, able to seamlessly share data between CPU and GPU - very very > > exciting. Hopefully that'll work it's way over to mobile computing in > > short order, where I think it'll have much more benefit (at least until > > Intel eventually ships a compatible extension in x86 ecosystems). > > > > Kevin N. > > > > > > > > On 7/10/13 2:02 PM, DarkStone wrote: > > > Hi Carlos, > > > > > > The benefit of enabling Stage3D for Flex would be: > > > > > > 1. Much better performance on mobile devices. > > > > > > 2. Be able to develop Real 3D Apps and Games. > > > > > > 3. Making Flex the best cross platform native app developing SDK. > > > > > > In fact you can use Stage3D directly in Flex Applications, Stage3D > > layers are below the Flex Application layer. But you can not take any > > advantages of Flex like MXML, Bindings, FXG, CSS etc. Cuz the current > Flex > > is not design for the Stage3D kind of things. > > > > > > In order to enable full support of Stage3D for Flex, it requires > > redesign Flex Framework from the ground up. Cuz Stage3D is about GPU > rather > > than CPU, and the GPU Programming is quite different than CPU, you need > to > > understand and deal with vertex, mesh, shader, texture, AGAL... > > > > > > However there are still some feasible ways to enable Stage3D for Flex, > > here is one I thought of: > > > > > > Redesign the Flex Framework by building it on top of the Starling > > Framework, this approach can reserve most of the Flex API names, for > > example UIComponent Class, FlexSprite Class etc. They are still the same > > class names and package names, but they need to extends the Starling > Sprite > > Class instead of the original one. And of course, a simple extends > Starling > > Sprite Class ain't gonna work, we will have to reimplement all of the > > subclasses, yes it's hell. > > > > > > Anyway, unless someone can invest a million dollars on this, I don't > > think full Stage3D support for Flex will become reality in these years, > > although personally I want this so bad. > > > > > > > > > Sent from DarkStone's iPhone > > > > > > 在 2013-7-11，0:38，Carlos Rovira <carlosrov...@apache.org> 写道： > > > > > >> Hi, > > >> > > >> from time to time people comes with the desire to see Flex running on > > >> Stage3D. I would want to recopile all the state of the art info about > > this > > >> topic and see if is possible and how much work it would require. > > >> > > >> I know people like J.Campos did two attempts and get valious research > > from > > >> that experience. There's things to get into account like > accessibility. > > >> > > >> Please could people share in this thread the things they know in order > > to > > >> recopile all info? Is there some things to take into account that > could > > >> make Stage3D not possible for Flex? Could we overpass it and make it > > >> possible? If it would be possible...it will brings real benefits? > > >> > > >> If some work is done in this topic, I'd propose to make focused in > this > > >> particular thing and unlike FlexJS, here I will not try to break > > >> UIComponent in small parts, or break compatibility. Even if it could > be > > >> possible to have a global flag like "enableStage3D" to make our apps > > run on > > >> Stage3D if is true or remain in normal display layer, it could be > great. > > >> > > >> Thanks in advance for any insight regarding this topic. > > >> > > >> Best > > >> > > >> Carlos > > >> > > > > > -- *Thomas Wright* Software Engineer Extension: 1054 Office: [801] 464.4600 Corporate Division twri...@yesco.com
