The last time I saw webgl working was testing Unity 3D webgl. Unity invest much effort and they got it working, but mainly on desktop, and without great performance. In mobile devices, was not supported (that was about 6 month ago), and when playing on iPhone (for example) was really bad experience.
I think webgl is not here yet...at least for what I see. If it could be I think Adobe smart people would make it 2017-01-13 16:18 GMT+01:00 Dev LFM <developer...@gmail.com>: > Actually it would be more easy, if adobe just convert their flashplayer to > render on webgl and that would work for all... > > 2017-01-13 15:15 GMT+00:00 Dev LFM <developer...@gmail.com>: > > > Hi all, > > > > For me, as I since 8 years constantly developed content editors for > > printing labs (basically I would use a Canvas on FlexJS), it was the no > > crossbrowsing differences, one player that behaves the same on all > targets > > (This is the key). My company currently relies on Flash to sell.. and > > html/js fails on this hard... so in the end I will probably deploy a Air > > release.. > > > > Then it was the IDE with good tools for productivity and debug. It is a > > waste of time patching to solve some IE/Firefox/Chrome issue.. > > > > Thats why, and listen to this pls, the most valuable thing that FlexJS > can > > sell, is the Stage3D/WebGL targets as replacement to flashplayer. Then > with > > Cordova for mobile, and Electron for desktop, we would target everywhere > > and win marketshare like in flex/flash did. > > > > We should get that flexjsstage3d from http://matrix3d.github.io/assets/ > > html5/flexjsstage3d/bin/js-release/ and help him finish all > compatibility > > with flash stage3d, then port the starling/feathers and we would be on > top > > again. > > > > AMF and ResourcesBundles / I18N are a must, modules could wait.. > > > > This is my vision for the future. > > > > > > 2017-01-13 13:58 GMT+00:00 Harbs <harbs.li...@gmail.com>: > > > >> I agree with Chris that target #1 is developers migrating from Flash. > >> > >> But, #2 is a very close second with JS developers looking for better > >> productivity. > >> > >> #2 is where we can have a real win in terms of adoption. I think the > >> reason js developers seem to always flutter from framework to framework > is > >> that they’re looking for better efficiency and not really finding it. > >> > >> I’m not sure what the minimal feature set for version 1 is, but I’m not > >> sure what percentage of enterprise apps use AMF modules and resource > >> bundles. It would be interesting to know if there’s any indicators on > that. > >> > >> On Jan 13, 2017, at 10:44 AM, Christofer Dutz < > christofer.d...@c-ware.de> > >> wrote: > >> > >> > Well from my point of view it was the whole “write once run > everywhere” > >> thing. > >> > I was totally annoyed of having to write UI things once and then patch > >> and bugfix things for all the other Browsers. > >> > > >> > But in general I think you (Alex) and I have one great difference in > >> our assumption of who will probably be our generation 1 users. > >> > > >> > You assume it’s mainly the people wanting to create new applications. > >> That’s why you see 1.0 the way you do it. > >> > > >> > I, on the other side, think that our generation 1 users would probably > >> be people migrating legacy Flex applications to FlexJS. > >> > > >> > The reason, why I think that way, is that no matter what bank or > >> insurance company I have worked for in the last 4 years. I always > encounter > >> Flashplayer maintenance updates. I usually ask why Flash? And always get > >> the answer: “We still got some legacy applications that need that”. A > >> little more investigation usually shows that there are loads of > >> applications still in production internally which are built in Flex. > There > >> are plans to migrate to JavaScript, but there just isn’t enough budget > to > >> simply rewrite something with the only benefit in the end being no > longer > >> to require the Flashplayer. For me “Flex” is stigmatized. Even if it’s > not > >> deserved, it’s still a reality. I doubt that someone wanting to try out > the > >> latest cool stuff will tend to go directly towards a stigmatized > >> technology, not if there’s all the cool React, Angular2, Typescript and > >> similar stuff out there that does “the same we promise to provide”. > >> > > >> > If we get FlexJS to a point where it’s easy to migrate we sort of > offer > >> the only option the people stuck in a dead-end with Flash have to > migrate > >> to JavaScript at a fraction of the costs. That’s why I’m continuing to > >> argue to add the most essential Flex features to FlexJS. It doesn’t > matter > >> if AMF support is slower than JSON or than AMF was on Flash. It just > have > >> to be there to ease the migration path. Same with skinning. It’s been > used > >> quite a lot and this I one concept where migrating isn’t just a matter > of > >> replacing some classes. If there is no skinning support all the > Components > >> have to be completely rewritten. Eventually we could do without modules, > >> even if I think they are essential, but for me it’s: > >> > > >> > - AMF Support > >> > - Skinning > >> > - Modules > >> > - ResourceBundles and I18N > >> > > >> > Which we need in order to ease the migration path. > >> > > >> > Chris > >> > > >> > > >> > Am 13.01.17, 00:24 schrieb "Alex Harui" <aha...@adobe.com>: > >> > > >> > > >> > > >> > On 1/12/17, 12:46 AM, "carlos.rov...@gmail.com on behalf of Carlos > >> Rovira" > >> > <carlos.rov...@gmail.com on behalf of > carlos.rov...@codeoscopic.com> > >> wrote: > >> > > >> >> We need some strategy, and we must think about what others are giving > >> in > >> >> comparison with us. > >> >> In LTE I think our solution win, but right now is complicate convince > >> >> business to choose us over Angular/React, since is world trending. > >> >> > >> >> So I'm with Chris that we need to give things others doesn't have, > for > >> me > >> >> maven is one of that things, but is something in the backstage. > >> >> We need more things on that make us different. One of those things is > >> AMF, > >> >> and since many Flex apps out there have it is a key point to make > them > >> >> move > >> >> to FlexJS. > >> > > >> > I guess I'm wondering why folks chose Flex in the first place. Was > >> it > >> > some cool feature? If so, what was it? My assumption has been > that > >> the > >> > real reason folks chose Flex (or maybe the reason they stayed) was > >> about > >> > Developer Productivity. A feature fight will be very difficult for > >> us to > >> > win without more contributors. Any feature we can produce as an > >> advantage > >> > would likely be short-lived: the other frameworks will simply > >> produce the > >> > same feature. > >> > > >> > But we can win or at least compare more favorably on helping you > get > >> your > >> > app into production faster and having fewer maintenance issues > >> because we > >> > are a single-source provider of both a declarative language and an > >> > object-oriented language and have a tool chain in our workflow. > >> And, I > >> > still believe that having a SWF version of your app will be very > >> valuable. > >> > For those who are interested in modules, without the runtime > >> verification > >> > that Flash has, you will be at the mercy of any synchronization > >> issues > >> > between the code that loads the module and the code in the module. > >> Flash > >> > will tell you right when the module loads that it doesn't meet the > >> > interface contract. When will you find out when running just in > JS? > >> > > >> > My 2 cents, > >> > -Alex > >> > > >> > > >> > > >> > >> > > > -- Carlos Rovira Director General M: +34 607 22 60 05 http://www.codeoscopic.com http://www.avant2.es Este mensaje se dirige exclusivamente a su destinatario y puede contener información privilegiada o confidencial. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción. De la vigente Ley Orgánica de Protección de Datos (15/1999), le comunicamos que sus datos forman parte de un fichero cuyo responsable es CODEOSCOPIC S.A. La finalidad de dicho tratamiento es facilitar la prestación del servicio o información solicitados, teniendo usted derecho de acceso, rectificación, cancelación y oposición de sus datos dirigiéndose a nuestras oficinas c/ Paseo de la Habana 9-11, 28036, Madrid con la documentación necesaria.
