Thanks for these. I’ve got a few initial comments so have put these here. I think for the most part we are looking at keeping our first SDK release very simple, and then once we’re properly up and running we can start looking at things like these!
1) Allowing more memory for textures in GPU. Current limit is 512mb which is way low nowdays.
[AF] Should be possible I would hope!
2) Improvements in multi threading. Removing FPS limit on workers in mobile devices which is now hard coded to 4 FPS.
[AF] I’ll talk to Adobe to see why this was put in place – we have a customer using Workers on an embedded platform and didn’t have any such restriction afaik..
4) Improvements in audio api and fixing bugs like sound play delay on Android.
[AF] Playback delays are a right pain, and have been from the start! We can look into this, but I know that different devices and chipsets have different characteristics so some of this may be tricky. Some of the recent updates from Adobe have been to try to push a/v further onto the platform, rather than handling it internally, so we can see how that goes.
5) Improving context3d so that context is not lost so easily on android devices.
[AF] Not sure about the possibilities here, my understanding was that the context loss was enforced due to the underlying Android OS, we can check..
6) Improving performance anywhere possible. Adobe focus was not on performance.
[AF] We’ve often been looking at performance 😊 so yes, highlight any issues, and we can take a look!
7) Improving performance for Windows 64. Currently my tests show that Windows 32 bit has better performance than Windows 64 bit. You can see more about that here: https://forum.starling-framework.org/d/20719-air-win-64-bit-captive-much-slower-than-air-win-32-bit-captive
[AF] Curious! But that would come a bit later when we start picking up the desktop platforms..
8) Making many of the AS3 methods compatible with object pooling like for example Matrix.transformPoint
where it would be great to supply another parameter (in this case Point object) where to write the result instead of creating new objects on every call.
Currently Matrix.transformPoint and many other methods create many objects. We do not have option to use object pooling and save on memory allocations and avoid triggering GC a lot.
[AF] Do you have a full list of such APIs? We can scan through them I suppose but a lot of the 3D cases I thought were already covered..?
Also Making Event.ENTER_FRAME dispatch one event object instance every frame not creating new Event object instance on every frame.
[AF] Interesting idea, we may need to look at this. It should be possible to have a form of cache/reset mechanism so that it would appear to be a new AS object, but the actual memory used for the object’s representation within the VM could be fixed. (Placement new operator, and all that..)
9) Fixing Context3D.clear method performance on Android. You can find out more about it here https://forum.starling-framework.org/d/20563-context3dclear-and-waiting-for-gpu-is-killing-performance-on-ios
[AF] Sounds interesting. We can take a look when time allows..! – with similar issues on our existing customers products, we tend to export the generated OpenGL ES calls so that we can put together a pure OGLES C++ application to run without the distraction of the AIR runtime or VM. This sometimes highlights issues but they have sometimes then been caused by the underlying implementation/drivers.