Creator-Defined Displayables - reusing Renders?

[rames44]

The example Creator-Defined Displayable at https://www.renpy.org/doc/html/udd.html creates new Render objects each time it is asked to render itself.

Given a CDD that will be updated frequently, is it legal to create a Render once, hold on to it, and return the same instance from each call to render()? (In order to cut down on allocation/deallocation of underlying resources.) Ditto for child Renders that would be used to help build the Render being returned?

My concern is whether the Ren'py code that uses the returned Render does anything explicit to "free" it after having used it, as opposed to just letting the garbage collector clean it up.

Having asked that question, I'm fully aware of the following:
1) You'd have to clear the Render's contents each time around, since otherwise you'd have the previous render's pixels still lurking around.
2) A Render is not pickle-able, so you'd have to swizzle with the data that is pickled and unpickled if the CDD was on the screen at the time the game was saved, and be prepared to recreate your Renders after being "loaded."

[Remix]

You should likely take a look at renpy.display.particle.SpriteManager and the way it uses SpriteCache (or rather the way it doesn't as the Cache is just a renpy object implying any caching is done in the background no matter the displayable type)

The image cache size is governed by config settings, which also implies the game keeps in memory old surfaces until it hits that limit and then cycles them around to use for new images.

In general, Ren'Py tries to reuse surfaces where they fit best ( a new full screen pic is most likely going to grab a surface from a previous full screen pic, a 40px square pic is going to try to get a similar sized surface or create a new one ) and prefers to reuse ones with the same tag where it can.

So, basically (and I might not be perfectly accurate here), after showing an image, Ren'Py puts the cached surface into memory. If on the next frame that image is no longer shown it will allow it to drop down the stack (find suitable surfaces for all current displayables might push our surface cache from top 5 to just in top 10). Another frame, no show of our surface, it might drop further... At some point, if not used the surface will either be de-allocated from memory or just grabbed to show a different image on...

Conclusion: I doubt that you will see many if any performance gains by trying to manage the pygame surface cache system yourself... I could be wrong though and (other than the save/rollback etc pickling issue) there is no harm in trying.

[rames44]

Ya, you’re quite possibly right, particularly wrt the Render returned. But if the child renders require non-trivial setup, it would seem efficient not to repeat that each time. So it might be less about the alloc/dealloc, and as much about recusing the number of other operations.

But thanks for the pointer to SpriteManager - I’ll have a look at it.