I think with some examples around for huge worlds with background model loading, it might be useful to collect ideas about background threaded texture loading.
I (and others) have experienced the same phenomenon llama mentions here:
Well, maybe it could just be the texture thing.. but file reading seems to have the ability to more damage than just to the thread it's happening from.
So, even if TextureManager.load was not depending on being called in the rendering thread (which it is, I believe), there would still be problems with stuttering since file loading generally appears to be capable of locking the main vm thread. Maybe. This could as well be a false conclusion, however. Does anybody have actual information about that?
Also, loading textures outside TextureManager sacrifices it's advantage of loading used textures only once. TextureManager now seems to use different image loaders dependent on file extension. Could that mechanism be extended to provide users a way to register their own image loaders?
That would be a start. Even better would be an opportunity to use custom loaders for textures, either by making the texure loader system pluggable, or by having a way of storing your own key/texture pairs in the manager. With the little I know now, I'd prefer the latter. I will try and implement that to see how it works out.
I have another point for texture loading: multiple views (gl contexts) should work. Currently the implementation allows a single scene to be rendered in one context only as each texture has a single texture id for the context that was active in the first apply. Any chance to get this in sync with your idea, Llama? When should the ids be generated and where would you stiore them?
Well, it's done with the WeakIdentityCache class I created (in jme.util). So you could have one per context (LWJGLRenderer) or one for all. I don't know actually… are texture ids shared amongst different contexts? Or only PBOs and such?