Use multiple threads to load textures asynchronously.

[j-jorge]

This PR modifies TextureCache to use multiple threads to handle the work of AddImageAsync. The number of threads is set by std::thread::hardware_concurrency().

TextureCache now uses std::unique_ptr to make clear the ownership of data structures related to asynchronous texture loading. Redundant field _asyncRefCount has been removed. Uses of std::deque has been replaced by the more straightforward std::vector.

I've tested this in my app on my phone as well as, with ThreadSanitizer enabled, on my laptop.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[j-jorge]

Any reason for not merging this one ?

[halx99]

/gemini review

[gemini-code-assist]

Important

Installation incomplete: to start using Gemini Code Assist, please ask the organization owner(s) to visit the Gemini Code Assist Admin Console and sign the Terms of Services.

[halx99]

/gemini review

[halx99]

Any reason for not merging this one ?

Reasons for Not Merging this PR

1. Maintenance Stage of Axmol 2.x
   Axmol 2.x has entered its maintenance phase. At this stage, we no longer accept large-scale feature changes, focusing instead on stability and long-term support.

2. Theoretical Considerations
   Texture loading involves two distinct steps:

   • I/O (file reading)
   • GPU data upload
     While I/O can theoretically be offloaded to other threads, the GPU upload process remains strictly serial. The actual performance benefit of adding multi I/O threads is therefore questionable, as the bottleneck persists in the upload stage.

3. Performance Feedback
   Developers have reported that on mid- to low-end devices, performance may actually degrade when using multi-threaded texture loading. This raises concerns about regressions in common usage scenarios.

4. Future Direction
   If, in the future, both texture I/O and GPU uploads can be executed in parallel threads, this PR would become significantly more meaningful. At that point, we would likely consider leveraging the existing job system rather than introducing a separate dedicated thread.

---

🙏 Thank you very much for your contribution and effort on this PR.
Even though it will not be merged at this time, your work and ideas are valuable to the project and may inspire future improvements.