Xith regression from SVN #2

Engines, Libraries and Tools Xith3D Forums
#1

I am sometimes, but not always, seeing the following

java.util.zip.ZipException: invalid stored block lengths
at java.util.zip.InflaterInputStream.read(Unknown Source)
at java.util.zip.ZipInputStream.read(Unknown Source)
at java.util.zip.ZipInputStream.closeEntry(Unknown Source)
at java.util.zip.ZipInputStream.getNextEntry(Unknown Source)
at org.xith3d.loaders.texture.TextureStreamLocatorZip.openTextureStream(TextureStreamLocatorZip.java:83)
at org.xith3d.loaders.texture.TextureLoader.getTexture(TextureLoader.java:671)
at org.xith3d.loaders.texture.TextureLoader.getTexture(TextureLoader.java:781)
at org.xith3d.loaders.texture.TextureLoader.getTexture(TextureLoader.java:795)
at org.xith3d.ui.hud.base.LabeledStateButton$Description.setTexture(LabeledStateButton.java:75)
at org.xith3d.ui.hud.utils.WidgetTheme.getCheckBoxDescription(WidgetTheme.java:311)
at org.xith3d.ui.hud.widgets.Checkbox.(Checkbox.java:170)

#2

This is strange ??? rafa_es described such an exception, too. But I cannot really fix it, when I don’t get this exception, too. But I’ll try to investigate. Thanks for the hint.

Marvin

#3

I tried to find the problem, but wasn’t able to trace it. Could you maybe send me en example, where the Exception is thrown? Even if it is not always thrown, it could help me.

Marvin

#4

Hi,

I think this is caused by these changes: http://xith3d.svn.sourceforge.net/viewvc/xith3d/trunk/src/org/xith3d/loaders/texture/TextureLoader.java?r1=328&r2=330

The buffering of the imput stream was removed and replaced by using mark() on the input stream. This CAN NOT WORK because of the following reasons:

  1. mark() may be called by the TextureStreamLoaders
  2. the stream is not reset() after a TextureStreamLoaders was called.

This will lead to an invalid stream position when a TextureStreamLoaders was not able to decode the stream.

I wanted to object to thís change - but I was unable to log into JGO for several month.

Ciao Matthias

#5

Well, what do you suggest to do for Zip loader? Do we need to cache all contained textures when the stream is opened? I would be happy to hear of a solution.

Marvin

#6

Ah okay so you’re still working with Xith3D ? What are you doing with it (if It’s not secret) ?

Anyway, nice to see you again.

#7

I’m currently not using Xith3D - I’m building my own 3D engine. That means that it’s unlikely that you will see any code from me for Xith3D in the near future.

And I don’t know what this TextureStreamLocatorZip is. But I think it will open a ZipFile and then return a InputStream for the requested entry. The resulting Texture is then cached (if enabled) - so I see no problem there.

In the mean time you can check out my website

Ciao Matthias

#8

I wrote this locator for the HUD theme system. There’re all Textures needed for a theme in one zip archive. I just realized, that I don’t seem to have finished the work on that locator. I wanted to make use of a cache for ZipEntries. I’ll have a look at it. Maybe I can easily remove the need for stream-marks…

Marvin

#9

I checked this thing. And now I remember exactly, why I decided to change this. And it should not be a problem. I modified the ZIP loader to solve the above problem.

It can :).

We can handle to not do this. So far it isn’t.

It is called by the TextureStreamLoader implementation in case it wasn’t able to decode the stream. So the stream position is valid for any subsequent call of a TextureStramLoader and is irrelevant, if the the stream could be decoded.

So it should not be a problem and is faster, because the stream is not copied into a byte array. And if the byte array stream reader calls mark(), it could lead to problems, if it couldn’t decode the stream and other loaders depend on the mark / reset system.

So the current solution should be faster and safer in any case.

Do you agree?

Marvin

#10

It may be a little bit faster - but not safer - the ByteStreamReader was being recreated for each loader - so it could call mark() and reset() as much as it liked.

But you should move the reset() out of the TextureStreamLoader because they don’t call the mark() method. Then change the spec that TextureStreamLoaders are not allowed to do mark() and reset() this will result in a cleaner (but restricted) API.

Ciao Matthias

#11

OK. Will do this tomorrow.

Marvin

#12

Done :).