Make use of Domain Memory.

[HaimZik]

Unlike previous efforts this implementation does not use one big ByteArray but switch between ByteArray
only for each ByteArray which is bigger than ApplicationDomain.MIN_DOMAIN_MEMORY_LENGTH(1024 bytes). There is no memory fragmentation because the largest allocation is the size of the max batch length. Context3d createVertexBuffer limit batch size to 65535 vertices and 256 byte per vertex, which is 16.77696 megabyte.
There is no (significant) impact on memory.
Apps which use high poly count will benefit, such as apps that use particle system.
I made a branch of the Particle System which make use of this update.
https://github.com/HaimZik/Starling-Extension-Particle-System

An performance analysis.
https://forum.starling-framework.org/d/21731-made-starling-use-domain-memory

[PrimaryFeather]

Thanks a lot for the pull request! I‘m currently on a vacation, so I haven‘t been able to look into it in detail yet. Domain memory usage has always been tricky, especially when attempting to integrate it directly into the framework and not have any negative side effects in some situations or on some platforms, so this needs to be carefully evaluated. I‘ll do that when I‘m back home!

[Fancy2209]

Thanks a lot for the pull request! I‘m currently on a vacation, so I haven‘t been able to look into it in detail yet. Domain memory usage has always been tricky, especially when attempting to integrate it directly into the framework and not have any negative side effects in some situations or on some platforms, so this needs to be carefully evaluated. I‘ll do that when I‘m back home!

Any chance this gets a review? From what I've read proper DomainMemory can really improve Starling's performance

[Fancy2209]

Thanks a lot for the pull request! I‘m currently on a vacation, so I haven‘t been able to look into it in detail yet. Domain memory usage has always been tricky, especially when attempting to integrate it directly into the framework and not have any negative side effects in some situations or on some platforms, so this needs to be carefully evaluated. I‘ll do that when I‘m back home!

@PrimaryFeather Any chance this gets a review? From what I've read proper DomainMemory can really improve Starling's performance
I am not sure if instead of changing the DomainMemory ByteArray, it'd be better for starling to expose a way to allocate a ByteArray from a main DomainMemory BA

[HaimZik]

@PrimaryFeather Any chance this gets a review? From what I've read proper DomainMemory can really improve Starling's performance I am not sure if instead of changing the DomainMemory ByteArray, it'd be better for starling to expose a way to allocate a ByteArray from a main DomainMemory BA

There is someone that done that, but then you need to handle fragmentation, so I choose to do something
more simple.

[PrimaryFeather]

I'm sorry that I never came back to you on this, @HaimZik – I can't remember what was going on back then; I think this was already after my contract with Adobe had ended, and I already had to cut my time working on Starling.

To be totally honest – I'm not a big fan of domain memory; it might make sense in some scenarios, but I'd rather have seen Adobe invest more time in optimizing the ByteArray class instead. From what I've seen, your solution is more carefully implemented than what I've seen before, and limits the changes to a rather small part of the framework – which is great work!

Still, considering the current place of Starling within its lifecycle, and regarding the limited time I can spend on it, I'd rather stick to the rule "keep it simple" and not make a change that cuts so deep into its low-level foundations. I don't want to take the risk of existing games running into problems. Especially considering how much faster Starling's target platforms have gotten in the time since you proposed this change.

I know this far from being satisfactory, but I hope you understand!