How to release the textures of a closed document

[hadi-rahimi]

Hello,

First, thank you for your great library! Second, I have a question:

I'm using release v5.1. When closing a document, I expect the textures to be released, but they still live in the internal texture database after close.

Is it intended and is there a way to release them? Currently I'm using Rml::ReleaseTextures() after close, but wanted to make sure whether there are better options.

[Paril]

I was actually going to ask a similar question; I had thought that maybe images were ref-counted/garbage collected in some way, but thinking more about it I assume it doesn't do that because most UI systems don't have "temporary" documents and keep most of their images around forever.

My first thought was that maybe you could mark clearable textures with a query argument in the URI or something (ie, image.png?cache=false) and somehow tie those names to the document so you can wipe them on unload, but I'm not sure how you tie them to the correct document since the texture system is far disconnected from the element that spawned the image...

[mikke89]

Hello, and thanks for the kind words!

You're right, we don't release textures automatically until the library is shut down. The idea is that many use cases involve showing and hiding elements with images, or rewriting the RML with images involved. Or even successively opening and closing documents. In such cases, the assumption is that one normally want to keep textures around so that they don't need to be reloaded unnecessarily.

I understand this behavior doesn't fit all use cases, and indeed, calling Rml::ReleaseTextures() is the intended way to release textures in such scenarios. So I would suggest to continue using this in your case. One perhaps unfortunate effect of this is that it releases all textures, even those currently visible in a document. You can also release individual textures, but I understand that this would only be helpful in some specific use cases.

We actually used to have reference counted textures through shared pointers (in RmlUi 5.1), but even then we never actually released them for the above-mentioned reasons. So during the rewrite of the texture database for RmlUi 6.0, I got rid of the reference counting all-together. Maybe it would be nice to re-introduce reference counting, and at least give that ability to garbage collect/release only textures that are unused.

Since texture resources are shared between documents, I don't think marking individual textures for garbage collection at the document level is the right approach. But perhaps having a manual garbage collection as outlined above would be sufficient for most scenarios?

[hadi-rahimi]

Hello,

Thank you for your detailed answer.

Rml::ReleaseTextures() works. I just wanted to make sure that I'm not misusing the library or missing something.

Granularity in textures life time would be a matter for embedded users mostly, as in my case.

I didn't come up with a specific idea, but generally speaking, a possible approach would be to let users somehow manage the life time. This way library doesn't have to worry about it and users will have more flexibility. And of course, with flexibility comes a bit of complexity for users.

[Paril]

Agreed, we definitely need something like this.

One use-case we have is that we tend to do a "vault" of sorts with games where we put in unused content; we don't want this content to stay alive outside of the vault UI and would prefer to just eliminate it once you back out of the Vault (and we precache it when you're entering the vault so you don't experience hitches when exploring it). This is very important for consoles especially; a lot of the content you browse would be images, and the Switch doesn't have a ton of GPU memory to spare, heh.

I don't think it's a good idea to do this at a global level, though, because there's still a lot of textures loaded that we do want to keep alive, even if the documents aren't open. You don't want hitches coming back when loading other submenus (although if we keep the images cached in our own texture manager, we can avoid them I guess).

[mikke89]

Hm, right, I can fully understand this need. Perhaps some global function that takes a source name (or perhaps a TextureHandle) and tells the library to automatically garbage collect it. Could that be helpful? Although, we already have the ability to release individual textures that way, but it's perhaps not always so easy to know when it's closed.

[Paril]

It's something I'd have to see the API and play with to know for sure I think. In our vault we're using a mix of and decorators to do the things we want to do, but on the plus side it does mean we know the names of the textures ahead of time that we don't care about keeping around...

[hadi-rahimi]

Yeah. I overlooked the new global function Rml::ReleaseTexture(...) in Core/Core.h in the latest master. It was not there in Release v5.1.
So I can do:
document->Close()
Rml::ReleaseTexture("/absolute/path/to/document/texture1")
Rml::ReleaseTexture("/absolute/path/to/document/texture2")
Rml::ReleaseTexture("/absolute/path/to/document/texture3")

That does the job for me, though in my use case, a document level function like this would be easier to use and to avoid hardcoding texture names which is a long list:
document->Close();
document->ReleaseTextures();

[hadi-rahimi]

As I'm looking, Rml::ReleaseTexture(...) gets an absolute path to the texture.
To make it easier to use, maybe you can borrow a feature from Qt/QML and introduce objectName to all objects (decorators, elements, sprites, etc). Then it will be like:

decorator: image("my_image1" icon-invader );
<img objectName="my_image2" src="/path/to/texture">

Rml::ReleaseTextureByObjectName("my_image1")
Rml::ReleaseTextureByObjectName("my_image2")

That can also be used on C++ side to find objects which is very useful. For example:

<div objectName="my_div"></div>

auto* object = context->Find("my_div");
auto* object = document->Find("my_div");

In Qt all classes are derived from QObject which is an empty class with just one member: string objectName
So all objects have it but it's optional to fill and use.

[mikke89]

Right, I see how this could be useful. However, we already have IDs for RML elements, which serves pretty much the same purpose. It could be useful for textures. But then again, it is very easy to setup your own mappings like that by using absolute paths as URLs.

E.g. use URL /my_fish_image whenever you want to use that image. When that texture is being loaded through the render interface, map this name to your own file path (or however you refer to your textures internally). Then, you can use the same path, also during the call to RelaseTexture, e.g. Rml::ReleaseTexture("my_fish_image").

[hadi-rahimi]

Yeah I can do that

Qt uses both id and objectName. I can make some guesses why.

Exporters (in my case html exporters) may change ids on export when you add or remove a component from UI or when you copy it to another space. So merging causes an overwrite of ids and that's a big issue. Because one may have hardcoded those ids in code to find elements. Having a separate id like objectName, fixes the merge problem.

Another small benefit is that objectName doesn't have the limitations of html id. So one can use spaces, special character, etc.

This feature is not much related to textures. I should have created another discussion for that.