Note on TextureManager

Troubleshooting General Help
1

i noticed that since a while, my jme project needs much more time to start.

well, after doing some rudimentay benchmarks, i put a breakpoint in TextureManager at the line where the cached textures are returned and started the app in debug mode. the unpleasant part was that while i use some textures multiple times, no "cache hit" happened, and the breakpoint wasn't reached. the obvious disadvantage is that textures are reloaded each time.



the problem is in TextureManager.loadTexture(TextureKey) :


TextureState state = null;
... // do some stff but don't touch 'state'
// the texture is cached only if 'state' isn't null (!)
if (state != null) {
  state.setTexture(texture);
  state.apply();
  m_tCache.put(tkey, texture);
}



it would be nice if a developer would remove that 'state', pull m_tCache.put(tkey, texture); out of the if statement and then remove the if . that should fix it.

EDIT: stupid me! the statement in the code above is false, but i let in, so the post can be understood. the textures are cached, but somehow i never get a "cache hit".

help!
2

All I can say is NCSoft has been messing around a lot with this lately… and then fixing it again. I guess it's regression?

3

i think we are in great need of some automated performance tests. running all the TestXXX programs are a great way to see if you have broken anything badly, but performance is often left behind…



some way of going through all the testprograms, firing them up, writing down how long their inits take, and then letting them run for 10-20 seconds and noting their average fps or something…and it should be something anyone could run, to see differences on their own computer…we could have a reference comp as well…then we build a nice database viewable from the net, and we got our own benchmark program s :wink:



i've done some automated tests like this before, when unit-testing is not enough…for our hockeygame we had problems with the puck going through the net sometimes(very seldom)…so i made a program that shot thousands of pucks from different angles as an automated test, so that we new right away if the collision code got broken…

4
sfera said:

i noticed that since a while, my jme project needs much more time to start.
well, after doing some rudimentay benchmarks, i put a breakpoint in TextureManager at the line where the cached textures are returned and started the app in debug mode. the unpleasant part was that while i use some textures multiple times, no "cache hit" happened, and the breakpoint wasn't reached. the obvious disadvantage is that textures are reloaded each time.

the problem is in TextureManager.loadTexture(TextureKey) :


TextureState state = null;
... // do some stff but don't touch 'state'
// the texture is cached only if 'state' isn't null (!)
if (state != null) {
  state.setTexture(texture);
  state.apply();
  m_tCache.put(tkey, texture);
}



it would be nice if a developer would remove that 'state', pull m_tCache.put(tkey, texture); out of the if statement and then remove the if . that should fix it.

EDIT: stupid me! the statement in the code above is false, but i let in, so the post can be understood. the textures are cached, but somehow i never get a "cache hit".

help!


I think the fact that they need a TextureState  is by design. For the cache to work the texture must already have it's id number. I subjected a fix on another thread, but it was ignored.
5

Your code was not ignored Badmi, it was discussed in the thread.

6
Badmi said:

The problem is this line in TextureManeger:

      
 if (state != null) {
            state.setTexture(texture);
            state.apply();
   
            m_tCache.put(tkey, texture);
        }



and this in Texture:

rVal.setTextureId(textureId);



What I suggest is something sumuler to the folowing:

In Texture:


public Texture createSimpleClone() {
...
rVal.setWrap(wrap);
setNext(Rval);
rVal.setLast(this);
return rVal;
}



LWJGLTextureState:


public void load(int unit) {
 ...
  texture.setTextureId(id.get(0));
  Texture tex=texture.getNext();
  while(tex!=null)
  {
       tex.setTextureId(id.get(0));
       tex=texture.getNext();
  }
  textureids[unit]=texture.getTextureId();
 ...
}




I can not fined any responses to the code above.
7

I don't see how this fixes sfera's problem. His textute is loaded and cached, but then when he tries to load it again, it's not recognized from the cache. If you want you can enlighten how your code helps solve this (it's not very clear to me).



If this is about multithreading, then you're in the wrong thread (and that has been discussed).

8
it would be nice if a developer would remove that 'state', pull m_tCache.put(tkey, texture); out of the if statement and then remove the if . that should fix it.


My code would of removed the state.
9

And that helps sfera's problem… how?

10

He asked for a way to remove the state, I offered a way to remove the state.

11

Where does he ask that???



I think he wants his program loads fast again, using cached textures instead of reloading them each time. I don't see anything about removing anything related to state or TextureState??

12
it would be nice if a developer would remove that 'state',


I believe that the statement above is asking for the removal of the state.
13

He’s talking about the if {} block, and what he says is crossed out, when you quoted him too.



Today’s forum hint: when people put a big black line right through the middle of what they said, take that into consideration when you reply :smiley:

14

He edited it while I was posting the first post so I did not see it.  :expressionless: The rest of the posts were just validating why I posted it so I ignored the fact that it was crossed out.

15

this has been a very fruitful topic to follow s :slight_smile:

16

i see the discussion is getting interesting (about "what sfera wants and what he doesn't" )  :slight_smile:

such a luck a certain frog didn't discover the topic yet  :lol:



back to the topic:



i'd have one more question: can anyone confirm this issue? didn't anyone notice any slowdowns when they start their applications? (i mean only the start, not the app itself)

@badmi: sorry badmi, i'd like to try your code, but there are no setNext() nor SetLast() methods in Texture.


17

Adding them was part of my idea (I did not show the code in the post since I thought that the implementation would be simple)



in Texture:

Texture next,last;

public void setNext(Texture n)
{
      next=n;
}

public void setLast(Texture l)
{
      last=l;
}

public Texture getNext()
{
      return next;
}

public Texture getLast()
{
      retuern last;
}

18

Ok, sfera and I tested this a bit, we did find a bug (I checked in a fix for this) but it might not have resolved everything yet.

19

Regarding ignoring code changes, etc. Use the issue tracker… thing won't get "ignored" there, but it's very easy to lose a topic in the forum, or just plain forget about it.

20

Well his code was not ignored… it was just established there are several ways for fixing this problem. It has to do with multithreading, and not with this thread.