TexturePool with power-of-2 bucketing for RenderTexture reuse #145

New issue

Open

opened 2025-11-29 00:28:51 +00:00 by john · 0 comments

john commented

2025-11-29 00:28:51 +00:00

Owner

Summary

Implement a TexturePool class that manages RenderTexture allocation using power-of-2 size bucketing. This would reduce texture allocation churn when frames with cache_subtree are created/destroyed or resized.

Background

This was identified during #144 (Universal Dirty Flag & Texture Caching System) implementation but deferred because:

No current demo validates its value
The core cache_subtree feature works without it
Memory pressure from texture allocation hasn't been demonstrated as a bottleneck

Proposed Design

class TexturePool {
    // Buckets: 64, 128, 256, 512, 1024, 2048
    std::map<std::pair<int,int>, std::vector<sf::RenderTexture*>> available;
    
    sf::RenderTexture* acquire(int width, int height);  // Round up to power-of-2
    void release(sf::RenderTexture* tex);               // Return to pool
};

When to Implement

Consider implementing when:

Profiling shows texture allocation as a bottleneck
Games create/destroy many cached frames dynamically
Memory fragmentation becomes an issue

Depends on: #144 (cache_subtree feature)
Part of: Performance optimization work

## Summary Implement a TexturePool class that manages RenderTexture allocation using power-of-2 size bucketing. This would reduce texture allocation churn when frames with `cache_subtree` are created/destroyed or resized. ## Background This was identified during #144 (Universal Dirty Flag & Texture Caching System) implementation but deferred because: - No current demo validates its value - The core `cache_subtree` feature works without it - Memory pressure from texture allocation hasn't been demonstrated as a bottleneck ## Proposed Design ```cpp class TexturePool { // Buckets: 64, 128, 256, 512, 1024, 2048 std::map<std::pair<int,int>, std::vector<sf::RenderTexture*>> available; sf::RenderTexture* acquire(int width, int height); // Round up to power-of-2 void release(sf::RenderTexture* tex); // Return to pool }; ``` ## When to Implement Consider implementing when: - Profiling shows texture allocation as a bottleneck - Games create/destroy many cached frames dynamically - Memory fragmentation becomes an issue ## Related - Depends on: #144 (cache_subtree feature) - Part of: Performance optimization work