Code fix so textures are render context-aware

I have developed a software patch that allows textures to be "aware" of the current render context.  Specifically, I have modified the Texture class to include a useContext() static method, to set the global texture context, and modified setTextureId() and getTextureId() so that texture IDs are mapped accordingly.



I also patched the DisplaySystem class to use java.util.ServiceLoader instead of the com.sun code.



BTW: Is there some way to reports bugs more directly, such as via bugzilla?  Also, how do I upload files via the forum?  Email me and I'll send you the two patched files.



–jon

Is there some way to reports bugs more directly, such as via bugzilla?

You can report issues at the google code issue tracker
but still make a post in the forum, the forum gets more attention then the issue tracker.

You can post patches in the contribution forum, if no one votes against it, it will get applied.


I have developed a software patch that allows textures to be "aware" of the current render context.  Specifically, I have modified the Texture class to include a useContext() static method, to set the global texture context, and modified setTextureId() and getTextureId() so that texture IDs are mapped accordingly.

Why would you need this? All rendering contexts in jME should be shared anyway so the texture IDs are valid for all of them.

I also patched the DisplaySystem class to use java.util.ServiceLoader instead of the com.sun code.

This has been complained a lot about in the forums and would be very useful if implemented.

There are several mechanisms available in LWJGL and JME for switching the rendering context.  These pretty much work as advertised, but textures do not recognize such context switches.  As such, when the context switches the texture caches says "I've got it", but the texture has the wrong texture ID for the current context.



Given a decent object model for JME (which apparently has never been documented) this would be quite apparent – the texture ID is currently associated with the texture only, instead of the texture-context combination.



I'll try posting the patch to the "contributions" forum.

I see what you mean now. Indeed if you have more than 1 canvas in your application each one uses a different context and they are not shared, but this shouldn't be necessary… In addition, you would have to write similar patches for display lists, vbos, and shaders so that they are also context-aware.



Ideally jME should share all contexts and then all texture IDs will be valid in all contexts, this is not only more convenient from a user's perspective but is also easier to handle from the driver's side. So I propose that instead of making textures context-aware, we change the DisplaySystem so that it shares all contexts created with the main context.

Correct me if I am wrong, but the implications of a "single shared context" is that there is one virtual world that can be viewed by multiple canvases.  In my application, I need to view multiple virtual worlds, with multiple canvases.  As such, I believe I need render contexts.



I think this is especially so when you throw in aspects of a virtual world and/or view that belong to the render state, and not model (i.e. scenegraph).  One such case, I believe, is the "background color".  If I have separate virtual worlds, and I want a distinct background color for all views of a given world, then I must associate the background color with the view and its renderer, and hence the render context.



If you throw in in-scene interaction, where the user is allowed to interact with in-scene objects or camera navigation, then you bump up against render contexts again, I believe.  Essentially, each view of the same virtual world needs its own camera and state.  In some early tests with JME (a long time ago, so it is a bit fuzzy), i recall that there are some issues with the association of the camera with the canvas, hence a further need for a separate render context for each canvas, not just for each virtual world.



In any case, to date I have only able to achieve multiple views of multiple worlds using rendering contexts.  From a purely OpenGL point of view, this makes sense, and the fact that JME render state and render state records are context-aware also makes sense.  Unless I am missing something it seems to be that either everything or nothing must support render contexts.  So far I can see no reason why it should not be the former (everything is context aware).

I didn't really explain it correctly… An OpenGL context is bound to a single display or canvas and that cannot change. So, each canvas has it's own context and this cannot be changed. However there is functionality to "share" a context with other contexts, essentially you can make a "master" context and all objects created in any context shared with it will be valid in all other shared contexts. There's no such thing as "view" or "world" in OpenGL, you just send commands saying "draw this" to a context, however each context does have it's own state machine which needs to be managed.

Agreed. OpenGL has no sense of "view" or "world", but one would hope that scenegraph based frameworks, such as JME, does.



I think we've beat this dead horse enough.  If you do not need, nor see the need for contexts then so be it.  My early prototyping with JME indicates that I need them.



In any case, the fact that JME its rather schizo when it comes to contexts – some of it is aware of them, and some of it is unaware of them – is not a good situation.  I'm sure you can appreciate that.