Re: About Statege3D in Flex
APU was used before they released hUMA (heterogeneous uniform memory access). APU really just means the CPU and GPU are on the same die. The idea was always to bring the two together more tightly, but earlier APUs still partition system memory between CPU and GPU, and when you want to move data from CPU to GPU, you have to copy it all - which is indeed fast in an APU. The thing that hUMA changes (which is in XBox One and PS3 - but I don't think is in any shipping mobile hardware yet, except AMD's Kabini) is when you want to change from working on data from CPU to GPU (or back again) you only need to send a pointer to where the data already exists in memory - there is no more partition, and no more copy. That's entirely different, and the biggest impact it will have is that it'll make life MUCH easier for programmers (at least I hope so). That is, unless I've misunderstood something (some of the DirectX 11.2 stuff has confused me a bit - but that might just be on the Intel side - I'm still reading up). Kevin N. On 7/20/13 10:01 PM, jude wrote: I thought that mobile devices were already eliminating this bottleneck through the use of the APU? Is this the same as what's going on in PS4 and XBox One? The first search result for APU actually mentions Flash in the video,http://www.geek.com/chips/what-is-an-apu-1304427/
Re: About Statege3D in Flex
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 写道： > >> 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 >>
Re: [FalconJS] populating the 'id' property at runtime
There are issues with the id of elements in HTML being unique. If they are not unique, they seem to have a negative affect on screen readers. I don't know if that would be a reason to disabled that, but it's something to know. It's for this reason (and the fact that document.getElementById only returns one element, not a collection even if there are more than one elements with the same id) that ASP.NET messes with all of your ids in a control (which ends up being extremely annoying down stream). As an alternative to using the browser's native id attribute (in cases where that might be a problem) you can use a data attribute: data-flex-id="myid"> Kevin N. On 4/15/13 5:25 AM, Tigran Najaryan wrote: I am trying to understand how to make sure the 'id' property is available on the DOM elements. It looks like if I simply modify function org.apache.flex.core.UIBase.prototype.set_id() to directly assign the 'value' to this.element.id it works, the id property becomes available at runtime and is shown by Firebug. Is there a reason why set_id() currently does not do it? If this modification is acceptable I will submit a patch. Tigran.
Re: [FalconJx] asm.js
Editing the compiler is a bit over my head, though I'm happy to through out comments on the generated JS code. Just to brainstorm a bit further, using the asm.js switch idea as inspiration, there is a way to finally use Alchemy right from within AS3. In thinking about what it would take to add support for this, it looks like certain features would need to be avoided to get that kind of speed out of it, even if using an AS3->JS compiler (like FalconJx). You'd need to strongly type everything (I already do that), and avoid some features of AS3 like dynamic types, and probably other features too. That's just on the semantics side, even while still using the normal GC stack. Adding a meta tag for ASM_JS in the FalconJx tool would work there for that half of what asm.js does. It could also be beneficial for both Flash and asm.js to mark "modules" (or perhaps a class in AS3) as "use heap"; (or AS3 meta tag) which would instruct the compiler to stuff all the class (or package) variables into a bytearray (alchemy) or typed array (asm.js) for faster execution, and to avoid GC hiccups. Currently from AS3 there is no way to use alchemy byte codes, because AS3 variables are garbage collected - this would solve that. The compiler would need a way to specify manual memory management for specific functions, classes and packages, the way Mozilla has done for asm.js modules. It would take adding malloc and free for code to use in those spaces, and some new compiler checks to make sure nothing in an heap class or module is out of bounds for this kind of AOT compilation. It seems like this could be taken care of in the compiler, without even the need for changes to AVM2, since the tools for this already exist in Alchemy (or could be written if Apache has no access to that). This would basically add a way to manually manage memory from withing AS3 through the Alchemy bytecodes in Flash or asm.js in JavaScript (or LLJS). Kevin N. On 3/27/13 6:26 PM, Erik de Bruin wrote: For now, we're using the Google Closure Tools (mainly the GCC with JSDoc annotation). This gives use the benefit of having our output (structured but human readable JavaScript) recompiled into highly optimised and minified 'release' JavaScript. Having said that, given the flexible way FalconJx is structured, it should be easy to experiment with a different type of JS output. I'm willing to help you get started, if you want. EdB
[FalconJx] asm.js
Any thoughts on compiling AS3 into the asm.js subset for super fast execution? http://asmjs.org/spec/latest/ I'm not clear to me what is required for memory management (is it required to simulate the heap, or is that optional?). Kevin N.
Re: [Git] Ignore files?
I like TortoiseGit for Windows. It's my favorite on any platform (I hear there's something similar on Ubuntu, but I haven't tried it). I'd love something like it for OSX. Kevin N.
Re: [Git] Ignore files?
Push and Pull have to do with syncing to a remote repo. You can still
commit to a local git (in fact you must, before you push or pull). The
big difference between git and svn is git keeps the entire history
locally, rather than only on a server like with svn. You can also just
zip up your local gitted folder, and send that in an email if you really
wanted (just watch out for accidentally sharing your private keys).
Kevin N.
On 3/12/13 8:05 AM, Erik de Bruin wrote:
Carlos,
I don't get it. Mike and I work together, so we need to have the same
codebase. When I have made a change that Mike needs to include in his
source, in git I do a 'push', in SVN I do a 'commit'. To stay up to
date with my code, Mike needs to do a 'pull' in git ('update' in SVN).
What's different?
EdB
Re: Flash and HTML 5
I'm curious if they could polyfill the canvas element on those 18% of browsers that don't support it using Flash. Kevin N. On 3/6/13 2:21 PM, Angelo Anolin wrote: Nice site. flashvhtml.com In summary, they're both just tools and taking sides with technology gets you nowhere fast.
Re: Language features
I do that too, but usually only when there is also a getter/setter (it's probably bad practice, but that's what I do). I also though it could work to use the "$" for private and protected vars, and leave public getter/setters unprefixed, but it still wouldn't be obvious that you are using a public property or method over a locally defined variable or function etc.. The @ symbol (as a replacement for "this.") would make it all much more obvious. Anyway, just an idea :-) Kevin N. On 2/12/13 12:39 PM, Avi Kessner wrote: Our coding convention is to preface all private vars with _ so you have _myVar as a private class scopes var and myVar as a method argument or temp var which only exists in the scope of the function. On Feb 12, 2013 6:27 PM, "Kevin Newman" wrote: This might seem like a minor thing, but I'd love to see a property shortcut similar to coffee script, so instead of this.whateverProp, it'd be @whateverProp. I know we can just omit "this." in AS3, but I think it's actually harder to read that when you come back to a code base after a few years (like I'm doing now). Using "this." or simply "@" to indicate a property would more clearly distinguish between property and scope chain variable, with a minimum of additional typing overhead. Kevin N.
Re: Language features
This might seem like a minor thing, but I'd love to see a property shortcut similar to coffee script, so instead of this.whateverProp, it'd be @whateverProp. I know we can just omit "this." in AS3, but I think it's actually harder to read that when you come back to a code base after a few years (like I'm doing now). Using "this." or simply "@" to indicate a property would more clearly distinguish between property and scope chain variable, with a minimum of additional typing overhead. Kevin N.
Re: Stage3D accelerated Flex components
I believe he was referring to the cancelation of AVMNext (and AS4) and FlashNext. Kevin N. On 1/30/13 4:08 AM, Frank Martin wrote: Daniel, what current announcement are you referring to?
Re: Stage3D accelerated Flex components
What are the bottlenecks, and how might they alleviate them? As far as I know, there isn't really any overhead when you upload a ByteArray or BitmapData, it's about as fast as you can get, as far as textures go. With vector data, they could reduce the type marshaling, but that seems like less of a problem than raw texture throughput. But texture throughput is limited in native apps too. Am I missing another bottleneck? Kevin N. On 1/30/13 2:31 AM, Daniel Freeman wrote: there are Stage3D bottlenecks that will impair performance for anything beyond games use-cases. If Adobe solve these technical obstructions
Re: Flash Platform Whitepaper
On 1/29/2013 8:14 PM, Tianzhen Lin wrote: I hope Adobe, with its new focus on gaming, would not repeat its misstep and make some waves into console market. The right play in my opinion would be to do exactly that - focus on gaming - then expand out to other types of apps like they did when Flash moved from animation, to video, to RIAs. They have a strong multi-platform app-store middleware product. But if you read closely, Adobe's narrative was never about a real focus on gaming, and was always more about leveraging their installed base, and desktop/laptop browser ubiquity. That failed when they couldn't sell premium features, and so they've cancelled the plans they had to advance Flash and AIR further, and have instead entered Flash into its end of life. It's really a shame they'll put stage3d and AGAL to sleep with Flash. Any hope they'll mix those APIs with a new language, and create a preplacement middleware product (I'm voting for GoLang as the core language!)? A new brand couldn't hurt at this point. Kevin N.
Re: Flash Platform Whitepaper
I read the whole thing as Flash entering sunset mode. Basically, Adobe doesn't want to make their AIR package competitive, so they are throwing in the towel, while allowing Flash Player in the browser to coast to it's inevitable demise. That's my read anyway. Kevin N.
Re: ASJS and Starling (was Re: [FalconJx] where I'm going to be)
Flex could do something more like they do on iOS. They can build an entire layout as one bitmap, but to get parts that can change or animate, they use layer-backing. So they only create a new quad for the parts they need to. This seems to be a better strategy on mobile than a deep display list, where everything gets it's own BitmapData and quad. Kevin N. On 1/21/13 11:46 PM, Alex Harui wrote: 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.
Re: ASJS and Starling (was Re: [FalconJx] where I'm going to be)
WebGL isn't supported by IE (and various flavors of WebKit and maybe not Opera either), so you'd have to do two implementations, one in WebGL, and a fallback in Canvas (which in IE is GPU accelerated). Kevin N. On 1/22/13 7:26 AM, Kessler CTR Mark J wrote: I was going to recommend trying a WebGL for GPU rendering. However, while most browsers support it. Microsoft has not yet jumped on board. It does use the HTML5 Canvas to render on. I didn't even remember it existed really until I read an article about a game from Mozilla demo studio called BananaBread. It was a "3D first person shooter game compiled to JS+WebGL". The part that caught my eye was the "Compiled into JS+WebGL". https://developer.mozilla.org/en-US/demos/detail/bananabread Are there any other well adopted standards similar to WebGL? -Mark
Re: Stage3D accelerated Flex components
On 1/21/13 3:31 PM, Arnoud Bos wrote: Hi Kevin, I like to read your blog and learn a lot from the many interesting code optimisations. But i'm not so sure about your statements for this particular one: Gah! Apparently I don't know how to read charts. This doesn't show what I though it does, or what I thought was the bottleneck . So nevermind, sorry for adding unneeded noise. :-) (That's not my blog, I was just referencing it for something I thought I saw on there, which upon revisiting, I can't see at all!) Kevin N.
Re: Stage3D accelerated Flex components
Your blog post says uploads to GPU are slow, but I think that's incorrect (or at least incomplete). I think the bottle neck is the conversion from BitmapData to the texture format ( /texture.uploadFromBitmapData())/. If you use texture.uploadFromByteArray you'll see much faster throughputs. Which suggest, the bottleneck is not with stage3d and texture uploads generally, but with uploads from BitmapData (which is what the old display list produces). You may even be able to handle and cache some of that BMD -> BGRA conversion yourself in MadComponents and gain a nice performance boost by using uploadFromByteArray() (at least when you can bypass redraw from the display list, which as I've said many times, is not well suited for a GPU workflow). More: http://jacksondunstan.com/articles/1617 Kevin N.
Re: TLF Editor UI source
Ah ha! http://blogs.adobe.com/tlf/2011/03/tlf-samples-now-on-sourceforge.html http://sourceforge.net/adobe/tlf/home/Home/ I guess these are separate from the Flex project? Looks like the license there is MPL. Kevin N.
Re: TLF Editor UI source
On 1/17/13 4:13 PM, Alex Harui wrote: On 1/17/13 1:08 PM, "Carol Frampton" wrote: On 1/17/13 3 :03PM, "Kevin Newman" wrote: Hi, I'd like to use the TLF editor code for a project I'm working on now. Is that code under the flex umbrella or is that still the property of Adobe. I'm talking specifically about the editor UI, not the framework. http://www.adobe.com/devnet-apps/tlf/demo/ The source of which was available in sourceforge (or maybe in a zip on some adobe blog post, I don't remember), but the folders are empty in the apache repo. Is that code available somewhere? The examples don't appear to have been donated. The only examples I could find are these but I don't think they include what you're looking for: http://download.macromedia.com/pub/opensource/tlf/textlayout_examples_07240 9.zip I did find the TLF 2.0 and 2.1 on sourceforge but the example folders were empty just like they are in Apache. Carol Devnet stuff is Michelle Yaiser territory. Michelle? I actually have the source to the thing, I just can't remember where I got it from. It was either from a sourceforge repo, or an old Flex blog post from Adobe. I think it was an examples.zip file posted somewhere.. Kevin N.
TLF Editor UI source
Hi, I'd like to use the TLF editor code for a project I'm working on now. Is that code under the flex umbrella or is that still the property of Adobe. I'm talking specifically about the editor UI, not the framework. http://www.adobe.com/devnet-apps/tlf/demo/ The source of which was available in sourceforge (or maybe in a zip on some adobe blog post, I don't remember), but the folders are empty in the apache repo. Is that code available somewhere? Thanks, Kevin N.
