Reply to thread

Message

Well, there are some weird aspects. The whole D3D texture handling in the Core lib definitely had issues, introduced by an unknown factor somewhere between Sept 5th and now. Like I said, DirectX disposes of the textures when it wasn't doing it before, and given MP's code wasn't tracking those events, the GUITextureManager ended up thinking it still had proper textures when they were actually invalid.

But, that only applies to textures kept in the GUITextureManager cache - and as far as I know when looking at the code this only happens when the code calls LoadTextureFromImage - meaning a plugin has created an Image and provides it as the source for the D3D Texture.
Most of the time - and in your plugin also if I'm not mistaken - the textures are based on pictures files. You provide a file name to a UI element - for example a GUIImage for the background - and the UI element is going to ask the GUITextureMAnager which is going to create a new texture from the file.
This doesn't use the cache, so a savage D3D.Texture dispose shouldn't mess up the display. Yet like you say, sometimes it does. And it also does weird things on my end even with my patch.
My guess is that some UI objects rely on the texture without re-asking GUITextureManager. I'll keep checking see if I can figure it out.

<blockquote data-quote="zeflash" data-source="post: 332401" data-attributes="member: 13641">Well, there are some weird aspects. The whole D3D texture handling in the Core lib definitely had issues, introduced by an unknown factor somewhere between Sept 5th and now. Like I said, DirectX disposes of the textures when it wasn't doing it before, and given MP's code wasn't tracking those events, the GUITextureManager ended up thinking it still had proper textures when they were actually invalid.But, that only applies to textures kept in the GUITextureManager cache - and as far as I know when looking at the code this only happens when the code calls LoadTextureFromImage - meaning a plugin has created an Image and provides it as the source for the D3D Texture.Most of the time - and in your plugin also if I'm not mistaken - the textures are based on pictures files. You provide a file name to a UI element - for example a GUIImage for the background - and the UI element is going to ask the GUITextureMAnager which is going to create a new texture from the file. This doesn't use the cache, so a savage D3D.Texture dispose shouldn't mess up the display. Yet like you say, sometimes it does. And it also does weird things on my end even with my patch.My guess is that some UI objects rely on the texture without re-asking GUITextureManager. I'll keep checking see if I can figure it out.</blockquote>

[QUOTE="zeflash, post: 332401, member: 13641"] Well, there are some weird aspects. The whole D3D texture handling in the Core lib definitely had issues, introduced by an unknown factor somewhere between Sept 5th and now. Like I said, DirectX disposes of the textures when it wasn't doing it before, and given MP's code wasn't tracking those events, the GUITextureManager ended up thinking it still had proper textures when they were actually invalid. But, that only applies to textures kept in the GUITextureManager cache - and as far as I know when looking at the code this only happens when the code calls LoadTextureFromImage - meaning a plugin has created an Image and provides it as the source for the D3D Texture. Most of the time - and in your plugin also if I'm not mistaken - the textures are based on pictures files. You provide a file name to a UI element - for example a GUIImage for the background - and the UI element is going to ask the GUITextureMAnager which is going to create a new texture from the file. This doesn't use the cache, so a savage D3D.Texture dispose shouldn't mess up the display. Yet like you say, sometimes it does. And it also does weird things on my end even with my patch. My guess is that some UI objects rely on the texture without re-asking GUITextureManager. I'll keep checking see if I can figure it out. [/QUOTE]