Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Async texture loading #131

Closed
nem0 opened this issue Oct 6, 2020 · 8 comments
Closed

Async texture loading #131

nem0 opened this issue Oct 6, 2020 · 8 comments
Labels
enhancement New feature or request

Comments

@nem0
Copy link

nem0 commented Oct 6, 2020

Hi, is there a way to make texture loading asynchronous? Right now RenderInterface::LoadTexture must load the texture before
the function returns, because it expects me to return dimensions. However I can't afford to synchronously load textures in the middle of frame, because that can cause stuttering.

@nem0
Copy link
Author

nem0 commented Oct 6, 2020

I discussed this with some other programmers and what could work too is RmlUi telling us what textures are referenced in advance, so we preload them and don't even try to render ui before are textures all loaded.

@mikke89
Copy link
Owner

mikke89 commented Oct 6, 2020

Yes, it's a good point. At least you don't want to load from disk in the middle of a frame. The way I do this is to load the GUI textures into memory during load-time. And then the textures are submitted to the GPU when requested by RmlUi during rendering. Seems to work fine for my use-cases.

For my case I have structured the documents and textures so it's quite easy to work out what is needed during which phases of the application. Could something like this work for you?

For more complex documents, or in general, I can see it being useful to know the textures in advance though. At what stage would you want to load the textures, just after loading the document?

@nem0
Copy link
Author

nem0 commented Oct 6, 2020

Structuring documents and textures so it's easy to figure out what to load is possible, but it's not very user friendly in general case. The list getter would be much better option. Anything before render works, could be after first update.

@mikke89
Copy link
Owner

mikke89 commented Oct 7, 2020

I agree it would be a nice option. Are you thinking of querying all textures that are visible, or all textures that are ever referenced? Globally or per-document?

@nem0
Copy link
Author

nem0 commented Oct 7, 2020

All textures, not just visible would be probably better, since textures can become visible any time. Global is enough for me, but per-document can be useful too.

@mikke89
Copy link
Owner

mikke89 commented Oct 7, 2020

Alright, it's helpful to know the requirements, thanks. I'll have a closer look at this at some point. It might be a bit tricky the way things are implemented right now, as each texture-using object decides when they want to load textures at their own merit, and there is no global way to get such a list until they do. Might have to do some restructuring.

@mikke89 mikke89 added the enhancement New feature or request label Oct 7, 2020
mikke89 added a commit that referenced this issue Oct 19, 2020
…. (It still won't actually be compiled until it is rendered). This allows listing and pre-fetching all image sources in the document, even if they are not displayed yet. See #131.
@mikke89
Copy link
Owner

mikke89 commented Oct 19, 2020

I made a stab at this, let me know how it works. It's only global, as adding per-document sources would require a lot more changes. I think I covered all the texture usages I could find, but let me know if there is anything that does not show up as it should.

@nem0
Copy link
Author

nem0 commented Oct 20, 2020

Thanks, it seems to work.

@mikke89 mikke89 closed this as completed Oct 22, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants