[fixed] Pictures : 1st transition sometimes buggy (1 Viewer)

[tourettes]

Re: AW: Pictures : 1st transition sometimes buggy

Yes. Although come to think of it I'll remove the 3 re-tries for syncronous texture loads since that could give a noticable delay. For asyncronous loads it should be fine.

1) Why do we have any synchronous texture loading at all? we should have some placeholder gfx that will be displayed when no texture is available yet.

2) We should find the real reason why the texture loading is failing instead of creating a workaround (MP1 wont fail )

 

[Baboonanza]

Re: AW: Pictures : 1st transition sometimes buggy

1) When you're opening a screen with icons on you want the icons loaded before the screen is displayed. It just looks better. Large images like covers and fan-art can be loaded asyncronously with a fallback image displayed.

2) I agree, but it's better to have it working than not working and since we don't even know what the problem is at the moment I can't promise I'll be able to fix it quickly. Besides, having 3 retries isn't a bad idea anyway.

Edit: I made a stupid mistake in the patch. I've updated the original post with the correct version.

 

[tourettes]

Re: AW: Pictures : 1st transition sometimes buggy

1) When you're opening a screen with icons on you want the icons loaded before the screen is displayed. It just looks better. Large images like covers and fan-art can be loaded asyncronously with a fallback image displayed.

Screens could be loaded with pre-emptive strategy. We wont have that many textures in the MP2 skins (fan art and thumbnails are the most resource hungry textures). 50Mb would be more than enough. We should have those loaded all the time. Fan Art, backgrounds, thumbnails and similar items should be always lazy loaded. This way the view changes won't ever require synchronous texture load operations that are making the GUI and animations jerky.

2) I agree, but it's better to have it working than not working and since we don't even know what the problem is at the moment I can't promise I'll be able to fix it quickly. Besides, having 3 retries isn't a bad idea anyway.

Having a workaround might cause us to forget that there is the real issue hidden in the code

 

[Baboonanza]

Re: AW: Pictures : 1st transition sometimes buggy

Screens could be loaded with pre-emptive strategy. We wont have that many textures in the MP2 skins (fan art and thumbnails are the most resource hungry textures). 50Mb would be more than enough. We should have those loaded all the time. Fan Art, backgrounds, thumbnails and similar items should be always lazy loaded. This way the view changes won't ever require synchronous texture load operations that are making the GUI and animations jerky.

That's how it works now. It not really practical to pre-load screens but once images are loaded they will stay in cache pretty much forever. These are small, local files anyway so loading on-demand the first time is hardly onerous.

 

[Albert]

AW: Re: AW: Pictures : 1st transition sometimes buggy

Having a workaround might cause us to forget that there is the real issue hidden in the code

tourettes, it's very kind of you that you bother so much about our code, but I think you should let Baboonanza do his work. He absolutely knows what he does.

 

[Smeulf]

Hi,

I would really like to know what the cause of the problem is though, and why you get it more than us. Are these pictures located on a network drive?

All pictures are stored locally. My OS is 7 x64. Can be a reason ?

You can see this when closing the context menu in the picture player and I think it is also the cause of the dropped video frames that tourrettes mentions in another post. We will work on it.

I'm not expert but sounds like a right way.

I still can't reproduce the problem even with DirectX full debug validation enabled. My best guess is that the DataStream is corrupt for some reason, perhaps related to me changing file access to asyncronous mode. I have attached a patch that should make the texture loading code more fault tolerant, could you please test it and see if improves the situation?

I've got new errors :

DefaultLogger.cs Line 216 / The index (0 base) must be greater or equals to 0 and lower than size or arguments list (Approxmimative translation, In french : L'index (de base zéro) doit être supérieur ou égal à zéro et inférieur à la taille de la liste des arguments.)
See detail1.txt. Sonds like a wrong call to the Debug() method : var Args = object{[0]} (I'm still not expert )

TextureAssetCore Line 402 (Patch applied) / NullReferenceExeption not managed : do "you" try to open the stream before it is loaded ? 'Cause _fileSream is Null... Maybe that's the main error. See detail2.txt

Cheers.

 

[Baboonanza]

Hi,

I would really like to know what the cause of the problem is though, and why you get it more than us. Are these pictures located on a network drive?

All pictures are stored locally. My OS is 7 x64. Can be a reason ?

You can see this when closing the context menu in the picture player and I think it is also the cause of the dropped video frames that tourrettes mentions in another post. We will work on it.

I'm not expert but sounds like a right way.

I still can't reproduce the problem even with DirectX full debug validation enabled. My best guess is that the DataStream is corrupt for some reason, perhaps related to me changing file access to asyncronous mode. I have attached a patch that should make the texture loading code more fault tolerant, could you please test it and see if improves the situation?

I've got new errors :

DefaultLogger.cs Line 216 / The index (0 base) must be greater or equals to 0 and lower than size or arguments list (Approxmimative translation, In french : L'index (de base zéro) doit être supérieur ou égal à zéro et inférieur à la taille de la liste des arguments.)
See detail1.txt. Sonds like a wrong call to the Debug() method : var Args = object{[0]} (I'm still not expert )

TextureAssetCore Line 402 (Patch applied) / NullReferenceExeption not managed : do "you" try to open the stream before it is loaded ? 'Cause _fileSream is Null... Maybe that's the main error. See detail2.txt

Cheers.

Thanks a lot for the extra info! It seems like it may be a threading issue, with the FileStream and/or DataStream being disposed before the Texture has been allocated, which would explain the random behaviour (though it is still slightly odd that I have never seen it, I'm on a quad-core machine with Windows 7 x64 too). I'll work out another patch tomorrow, hopefully the careful application of more locks should cure the problem.

 

[Smeulf]

I'm on a quad-core machine with Windows 7 x64 too

[Joke mode ON]

Maybe mine is just too fast

Or too slow for MP2

[Joke mode OFF]

 

[Albert]

AW: Re: Pictures : 1st transition sometimes buggy

I'm on a quad-core machine with Windows 7 x64 too

[Joke mode ON]

Maybe mine is just too fast

Or too slow for MP2

[Joke mode OFF]

Lol. But I really sometimes had threading problems that occured on my quad core and not on a dual core, or vice versa.
How many cores do you have, Smeulf? Which processor?

 

[Smeulf]

My CPU is AMD Phenom II x4 955 @3.2Ghz

See my system config for more infos.

Cheers.