GUIImage and / or Texture handling change in RC3 / RC4? (1 Viewer)

[zeflash]

Hi,

I was troubleshooting some image display issues in the MPTVSeries plugin (fanart), and got them fixed on my dev computer.
I moved my new version of the plugin on my HTPC, and the issue was still there!

After a while I figured out my HTPC was using a post RC3 SVN build, while my dev computer still had sources from Sept 5th. So I updated my MP SVN sources, and blam! nothing works anymore in my plugin

The problem: after I've played a tv show, upon coming back in the plugin view any GUIImage that had a custom bitmap showing up show as black instead. From what I can tell tracing the code in MP, the texture of those GUIImage have been disposed.

a specific example; in MPTVSeries, we show up a background fanart using a GUIImage control in the skin. In OnPageLoad, we load the fanart picture in the GUIImage using the SetFileName function.
After a playback, we do the SetFileName again - but the filename of the GUIImage hasn't changed, so nothing's done. Still, when the render occurs on the GUIImage, the texture object is disposed, so nothing's displayed.

That used to work prior to RC3, it's not working anymore. Even worse, in the latest SVN (RC4+ I guess) no banner whatsoever "survives" a video playback - when coming back from a playback everything is empty, even on the series list. Rating bitmaps are gone, season bitmaps are gone, etc.

So I'm wondering what path should I take to make it work again? How is a plugin supposed to handle the initialization / reinitialization of its skin objects? Is there a way to make those texture "persistent"? Should it be done like that? Or am I missing a step somewhere? What's the common way of doing such things? Were we doing things wrong from the beginning?
Everything's broken! Help!

 

[mattsk88]

I know the problem you speak of, yet it appears to be a fairly random problem, ie I'm running the latest SVN version of MP TV-Series and also the latest svn version on Mediaportal and I'm having no trouble. Yet I have experienced the problem before but not for awhile.

 

[tourettes]

Check if the logs are showing direct d3d device reset. In such cases textures are disposed. On Vista those resets shouldnt happen anymore (only on really rare cases) but for example on XP the exclusive mode is causing a device lost when video playback is used (nothing we can do about). So if a plugin is using its own textures, it should reload those when device is reseted (not sure if there is any events currently generated that you could observe).

 

[zeflash]

Alright, I think I know what's going on now. Seems to be a bug in MP
So - let's be precise in how the images are loaded & handled in the plugin.
When starting the plugin, most of the images (that disappear later) are loaded from a file, by the plugin, using GDI+.
Then it's passed into MP's texturemanager, with LoadFromMemory, under a name specific to the plugin ([TVSeries:filename]). texturemanager in turn makes a cachedtexture out of it, and store it in the cache list.
The various GUI objects of the plugin then use those cached textures.

Now, a playback happens. The D3D textures are disposed.

When the facade loads again in the plugin, I again call LoadFromMemory - which looks up the texture in the cache, and it's still in the cache - but it's been disposed! so it's not displaying anything, and the GUIListcontrol actually tries to load the texture over and over and over -the log grows quite fast)

So. There are many actions we can take. First of all, I don't see the point of storing the textures for all the series in my plugin - this means if there are 100 series, it will store 100 banners, instead of just using the ones that are shown at the moment. I'll probably change that so that I'm just passing along the filename of the banner.

But, there is still a logic issue in how MP handles cached textures. After a playback, even if those textures are still in the cache of texturemanager, they aren't valid anymore. So they should be cleared whenever the dispose happens.
And that affects the plugin, because there are some places where we have to use memory bitmaps (series without banners for which I create a "fake" banner with the series name written on it, composed logo bitmap made from multiple bitmaps, etc)

I wish I could propose a patch for MP, but I can't find where the dispose happens for Direct3D.Texture. Seems it happens from outside MP's code, as it's not done in cachedtexture.Dispose. I'll keep looking.

 

[tourettes]

but I can't find where the dispose happens for Direct3D.Texture

Without looking into code, I would assume its completely done on DirectX side. It would be applications responsibility to reload the textures when "device lost" event is received (of course after the device is reinitialized).

I'm more than willing to have a look on a patch that solves the issue

 

[zeflash]

What I don't understand is that this wasn't happening before - my SVN version from september 5th worked fine. So something has been changed in MP's code to trigger that D3D dispose. Maybe worth looking there.

 

[tourettes]

What I don't understand is that this wasn't happening before - my SVN version from september 5th worked fine. So something has been changed in MP's code to trigger that D3D dispose. Maybe worth looking there.

Basicly that dispose is triggered every single time when VMR9 + exclusive mode is used and video playback is issued (as changing to exclusive mode will be done only when video playback is in use).

You could try using Vista + EVR to see if its still happening. Btw. there is one bug that might affect this issue:

0001758: random characters both sides of tv-overlay in tv-home - MediaPortal Bugtracker

 

[zeflash]

Basicly that dispose is triggered every single time when VMR9 + exclusive mode is used and video playback is issued (as changing to exclusive mode will be done only when video playback is in use).

Not the case. On my system, the dispose happens whenever I play - be it VMR9 exclusive, non exclusive or EVR.

I've started working on a patch, there is a disposing even sent by the D3DTexture that we can use. when that happens, the cachedTexture.Frame is notified, calls Dispose, notifies whoever needs to be notified that the texture isn't valid anymore.
And GUITextureManager subscribes to the Disposed event sent by the CachedTexture (something not done right now), to check if a cachedTexture is disposed, and therefore remove it from the cache list.

Basically, the whole chain from D3DTexture to GUITextureManager needs to be reworked. I'd rather see GUITextureManager handles its cache only relying on the Disposed events, instead of calling Dispose & cached.remove. That way no matter what disposes of a texture, it's being taken in account.

 

[tourettes]

hmm... could it be that you have limited amount of video RAM and that is causing the dispose to happen (with large number of huge textures?).

But no matter what is causing it the patch is more than welcome

 

[zeflash]

Well, the amount of video ram should be 320MB, I don't quite see how that can be not enough
I'll keep on working on that and when my patch is done I'll submit it and notify you so that you can check that in.