Xith regression from SVN #2

[hawkwind]

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.<init>(Checkbox.java:170)
   

[Marvin Fröhlich]

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.<init>(Checkbox.java:170)
   

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

[Marvin Fröhlich]

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

Games published by our own members! Check 'em out!

[Matthias]

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

[Marvin Fröhlich]

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

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

[Amos Wenger]

but I was unable to log into JGO for several month.

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.

[Matthias]

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

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

[Marvin Fröhlich]

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.

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

[Marvin Fröhlich]

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 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.

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:

It can .

1. mark() may be called by the TextureStreamLoaders

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

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.

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

[Matthias]

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

Do you agree?

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

Games published by our own members! Check 'em out!

[Marvin Fröhlich]

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.

OK. Will do this tomorrow.

Marvin

[Marvin Fröhlich]

OK. Will do this tomorrow.

Done .