Support for Async File/Font Loading

[nikovacs]

Hi,

My project involved a client-server architecture. This means that any assets that the client may need must be served from the server. For that reason, I need to ensure that I can load files asynchronously. I already saw Issue 131 in which something similar was addressed. However, since I cannot promise that a file will be loaded by the time Rml needs it, I'd like to know whether it will re-attempt to load it on the next cycle if it was unsuccessful in the previous attempts.

I suppose my main question here is whether the LoadTexture method will be called again for the same asset even if it returned false (failed) the first time around.

[mikke89]

Hey there,

The library doesn't really target client-server setups, at least we don't make any special considerations for async operations. And the short answer to your question is "no", we don't try to load the texture again.

There is a longer answer if you're willing to try some workarounds to get the behavior you want. At least, here is an (untested) idea. First, after you have actually fetched the image file, call Rml::ReleaseTexture(name). I believe this typically expects no changes to the layout. Instead, if e.g. the dimensions are not known, and layout depends on dimensions, then you might need to manually dirty the document layout (set some fake property that would require redoing layout), and then call document->UpdateDocument().

Or, probably a more robust approach: Use a placeholder texture file, and then replace that with the correct source file once the image has loaded.

I hope you're able to work it out. Although keep in mind that this isn't really a target use case for the library. The async part ideally would be implemented on your side, and then RmlUi should be treated as a "synced" interface.

[nikovacs]

Thank you for the response Michael.

In my use case, I won't necessarily know which document is loading the element. Nor will I know the dimensions of the texture before it is loaded / reloaded.

If I understand correctly, there is not currently logic in place to dirty the layout if the dimensions of the image have changed?

In ElementImage::GetIntrinsicDimensions, could it be possible to add logic that, if the dimensions of the image don't match the previous, then to call Element::DirtyLayout? (I'm not too familiar with this code base, so forgive me if this is not even close to practical)

[mikke89]

For the <img> element in particular, this one certainly dirties the layout if either the image is changed (e.g. through the src attribute), or if the specified width or height is changed. However, the library generally expects that the underlying texture size does not change.

When the texture object is released, it doesn't know about its users (like the <img> element). So it cannot know which documents that would require a layout. That would be the client's responsibility to keep tabs on. The next opportunity to reload the texture comes when it's trying to render the image element. Since the texture fetch is done at render time, it cannot do any layout changes at this point.

So yeah, it's not really practical the way it seems you'd like it to work, it breaks a lot of assumptions and architectural decisions. I think you'll have to approach this a bit differently. Possibly involves keeping tabs on which image elements and documents are being used, use placeholder images, maybe make your own image element. I'm sure there are multiple options to consider.

[nikovacs]

I'll leave an update here, just in case you were wondering.

I was able to achieve async loading of documents in what is probably a very jank solution. I made by own FileInterface that used my server-retrieved assets (stored as strings). If the file was not yet retrieved, it threw the filename which I then catch in my own document factory which tells me what I need to request from the server.

This is also done using v8 bindings. Here is a code snippet to show how it works.

uiContext.loadDocument("userlogin.rml")
  .then(doc => {
      let loginBtn = doc.getElementById("loginButton");
      let onClick = (e) => {
          print("btn clicked from js with event type: " + e.getType())
      };
      loginBtn.addEventListener("click", onClick, false)
      doc.show();
  });

I have not tackled the reloading of images yet, but I suspect I may fork the repo and dirty the layout each time an image is loaded. That sounds inefficient, but it may suffice for my use case.

[mikke89]

Thanks for the update. The v8 bindings look very interesting.

Instead of forking the library, I would suggest to investigate making your own image element, and using that for <img> elements. You can start with simply copying our ElementImage, or deriving from it. Should be fairly trivial to add some logic to handle async images here, and dirty the layout once they're ready.