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