While working on my conversion plugin I stumbled across the following problem with the way the resource locator works.
My app can't asume that a certain texture is there, sometimes it is sometimes it isn't. SO I used the MultiformatResourceLocator to try to find em anf if it doesn't find em it should just skip it.
That works only with a small directory hierarchy because of the way (recursion) the locator is implemented.
If I look for a texture called maggie and it isn't there then this URL "file:/home/jochen/workspace/jmonkey/src/jmetest/maggie" results in a running time of about a minute on a dualcore 2.2 GHz.
A url like this "file:/home/jochen/workspace/jmonkey/src/jmetest/data/model/maggie" will not finish in any reasonable amount of time (I didn't have the patience to wait for iut to finish).
I did a quick hack and I am looking for textures now on my own.
I don't know you want to change that or not but as a suggestion I would say it owuld be good to be able to set a limit to the recursion depth or provide means that allow a user to specifiy fixed directories where no recursive descend takes place.
Maybe someone can explain why it takes so long. Is there a lengthy resolution time for URLs?
That's not the problem.
It takes so long because of the recursion. The amount of directories th recursion has to walk through grows exponential and that kills the performance from a certain point on.
Sorry, I am still a little off, had my bachelor party last night, so I just didn't have the brain to dissect the recursion used in there.
BUt some traces showed me that behaviour. It was easier writing my own code for resources than trying to fix it.