On 12/7/16, 9:07 AM, "carlos.rov...@gmail.com on behalf of Carlos Rovira" <carlos.rov...@gmail.com on behalf of carlos.rov...@codeoscopic.com> wrote:
>Hi Alex, > >IMHO this is a mistake for the following reason. I commented on this in >other thread: > >Nowadays SWF is not what it was some years ago. All we know this. We can't >sell a Flex app as we did back in 2006, but FlexJS has a great potential >in >the way we're building it. One reason is that we maintain our dev tools >and >lenguajed, other is that it outputs HTML, what clients wants nowadays. > >Until now for me Flash output was not as important, but taking into >account >the poor performance of HTML in mobile devices Flash output could be a >great solution for that problem but only if is built on stage3d to >leverage >the great performance benefits. > >I think accessibility would come later. But if nobody want the actual swf >output...it can be accesible that it would be for nothing. > >what about have a SWF output based on Starling? Volunteers are welcome to write to Stage3D. One does not prevent the other. I am not familiar with the Stage3D APIs so I would not be the person to write it. Personally, I would like to see some evidence that the display list performance is insufficient for the number of UI widgets in typical mobile apps. AFAIK, lots of folks are still using Sprite in their mobile apps. IMO, the problem with Flex mobile performance isn't the display list, it is the rest of the code that has to run before the display list gets updated. Most mobile apps I've seen don't need 3D rendering. Everything is flat 2D UI. The FlexJS SWF code is much lighter weight than Flex Spark. No need to solve a problem that doesn't exist, IMO. My 2 cents, -Alex
