renderer: use a dynamic list of FBOs instead of hard-coding them
The current approach was to pair each FBO with its use, "semantically". The intent was to minimize the number of "reallocations" that would be required if the number of passes changed dynamically (e.g. as the renderer options changed). However, this is not only an unrealistic design goal to optimize for (users can use separate pl_renderers for wildly different purposes, and for a single conceptual video stream it doesn't really matter), but also, it gets in the way of a planned refactor I have concerning `struct img`. Change this to make all FBOs dynamically allocated. The current implementation simply uses a counter, but a more advanced implementation could use a pool of textures and find ones that have matching sizes before recreating ones that don't. The API shouldn't change as a result of this.
parent
0386edd3
No related branches found
No related tags found
Loading
Please register or sign in to comment