Skip to content

Conversation

@greenpixels
Copy link
Contributor

Sorry for the delay, I am in the midst of other projects.

Please see #140 for more information. More specifically my #140 (comment) about this.

This PR introduces a internal _should_trigger_texture_load variable.
Now, instead of calling _load_texture_path, we now set _should_trigger_texture to true.

If it is true, we load every texture that has requested it in that frame.

This reduced the calls to _load_texture_path by 68% in my godot game project that uses this library.

⚠️ It is important to note that this introduces a 1-tick delay to texture loading.

@rsubtil
Copy link
Owner

rsubtil commented Jun 10, 2025

This proposal sounds great! From my testing on a benchmark scene (10k icons with random input actions, swapping between keyboard and controller), this results in a near ~50% performance increase (867.48 msecs to 452.59 msecs), which is great!

Before After
beforeInc afterInclusiveFrameN+1

Unfortunately, the one frame delay, which is fine during normal gameplay, is producing some side-effects on the editor. I suspect this has to do with the editor only redrawing when needed, and this is not being correctly picked up after the texture is loaded. Where this is most perceptible is in the path selector utility, where in the first frame, the icons do not load:
image
And, as soon as there's any input (e.g. mouse movement), the textures do load, but their sizes are not correctly propagated:
image

So this needs some more investigation. I'll also see if I can find the root cause of this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants