Strange for new jME compile

Ah, then not all that old :slight_smile:

No go with the new drivers… must be a hardware issue. I’ll keep looking into it to see if I can figure anything more out.



Funny thing is: This card supports OpenGL12 and GL_EXT_draw_range_elements based on what GLContext reports. Go figure!

Supporting it may just mean it’s able to do it in software mode. Unfortunately though, it makes it hard for us to detect and shift if we wanted to do that.

I’ve done some searching and the only thing I can find is something about arrayLocking when using VBO which is not working on a lot of earlier drivers. However, there doesn’t seem to be any references in jme to array locking… one way or another.



So, I really don’t know what the solution is other than adding a flag into the system. But that may be a little too invasive for an engine. I guess it boils down to how many end users will experience the problem, us developer types tend to have ‘bleeding edge’ systems, unlike the standard consumer. Of course that also depends on the market for your particular game.

So, doing my own profiling, it appears that we have only a few places creating objects. I was able to plug a few of these (related to grabbing screen coords and text.print) but a few are unavoidable (eg. some of the other string stuff related to showing fps and such…)



That leaves us with just two big ones, both related to the new render queues. In RenderQueue we use TreeSet, which means everytime we insert an item into the queue, a TreeMap.Entry Object is created. That’s the biggest item. The second and lesser one is when we go to render a queue and call iterator.



I don’t see an easy way out of either one… at least no alternatives that would be as fast and relieve us of the object creation. Maybe someone out there has suggestions. One thought is to manipulate gc… The other is to provide more memory… When the heap used is close to the max heap, gc happens a lot more often.



Anyhow, ideas?

I haven’t looked at the code (nor do I really know what it does), but just some brainstorming on this…



First off… providing more memory isn’t really what you want to do. Sure, it might help for now, but it’s not a long-term solution. That memory will get used in a larger game and you’ll have the same problem.



Next… Is it important that it’s a ‘Set’? Meaning, do all the items in the queue need to be unique? How much duplication would we get if it wasn’t a set? Not using a set may help eliminate some of the comparison checking that has to go on behind the scenes.



Whether or not you need a set, you could use a home-grown collection. Eg, an array with some code wrapped around it. You would drop the actual object into the array (no wrapper around it), and get it back out.



I don’t normally advocate doing this because it’s re-inventing the wheel, but sometimes with performance-critical portions of apps, it’s the only way to go. You could also then get rid of the iterator pretty easily by doing this, and eliminate any type-casting that I’m sure you’re doing when you pull the object out of the queue.



An alternative to using an array would be to re-create a type-specific tree-map/set. Then, put a little extra info on the object you’re queuing that is specifically for this tree-set to do whatever indexing needs to be done. Not the most elegant of solutions, and could break if used improperly, but it would eliminate the object creation and type-casting.



Also, if you do spin your own Tree-Map but don’t want to add anything to the object for indexing or whatnot, you could use an object pool for the wrappers.



That’s all I’ve got for suggestions. Not much help, I know… but again, if it’s really performance critical, it might be worth doing.





–K

I’ve considered some of these ideas, but the main issue is that we do require all items placed into the queue to be unique… each item is a scene element and is unique (in terms of construction, states, position on the screen, etc.) I use the TreeSets for the automatic sorting and have constructed Comparators for each of them (3 total) that set up sorting properly for the different types.



I agree that providing more memory is not a one-size-fits-all solution. I’m talking more along the lines of providing the appropriate amount of memory for your own personal application (and not just leaving that up to Java.)



On spinning our own collection, I’m hesitant only because the Java collections are tried and true and I’m a bit lazy. :stuck_out_tongue: Reworking the sorting and such will be a pain, but I suppose doable… I’m mostly concerned about eliminating the object creation encountered on inserts as it is one per rendered scene object (ie, Trimeshes and such, not Nodes.) The iterator is only potentially 3 object creations per frame max, so it’s less of a concern.



Anyhow, enough rambling from me…