GUIImage and / or Texture handling change in RC3 / RC4? (2 Viewers)
- Thread starter zeflash
- Start date
France
- Moderator
- #12
For what it's worth I just got a report from a Moving Pictures user describing something very similar. In some cases a texture is rendered all black rather than the actual image. The image handling is pretty basic in Moving Pictures as well, which implies to me this may not actually be a problem with the TVSeries code.
Or maybe we are both just doing the same thing wrong?
Or maybe we are both just doing the same thing wrong?
- Thread starter
- #13
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.
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.
I have noticed this behavour both in OnlineVideos & MP TV Series... I just loose my backgrounds, I have a double layed background with two png's with variant transparencies going on.. I use this in combination with the Autofullscreen plugin and I've noticed that the first time round entering these plugin's the image is there but once re-entering the backgrounds will disappear. That to me suggest the GUI engine rather than the plugin's... BTW this never happened pre RC3 as far as I can remember.
- Thread starter
- #15
I did more testing yesterday, this time with release builds, on my HTPC. With my fix, it seems everything now works ok. I still had some issues but that was with a debug build, that might have been the problem in itself.
I guess when the patch is approved and merged in the SVN codebase, we'll see how it goes for everyone else.
Edit:
my changes have been merged in SVN by RTV (thanks!) yesterday.
I guess when the patch is approved and merged in the SVN codebase, we'll see how it goes for everyone else.
Edit:
my changes have been merged in SVN by RTV (thanks!) yesterday.
- Thread starter
- #16
I've noticed the fix in GUITextureManager has been reverted :
"reverted changes of REV 20891 - sf.net #2322519 (Fix issues with D3D textures being disposed)
causing some basd side effects.
Texture disposition should only be done by the texturemanager itself"
What are those side effects? I didn't notice any using a version with the fix in. In fact, I just tested with the latest code (with the reverted file) and images are disappearing again after playback in MPTVSeries.
When actually stopping playback instead of letting it go to the end of the file though, this doesn't happen.
What I really don't get is this: " Texture disposition should only be done by the texturemanager itself". Well that's the point, it's not always done by the texturemanager, directX does it too. And if it's been done by DirectX and the texturemanager doesn't know about it, we have this bug.
Some explanations would be welcome here.
"reverted changes of REV 20891 - sf.net #2322519 (Fix issues with D3D textures being disposed)
causing some basd side effects.
Texture disposition should only be done by the texturemanager itself"
What are those side effects? I didn't notice any using a version with the fix in. In fact, I just tested with the latest code (with the reverted file) and images are disappearing again after playback in MPTVSeries.
When actually stopping playback instead of letting it go to the end of the file though, this doesn't happen.
What I really don't get is this: " Texture disposition should only be done by the texturemanager itself". Well that's the point, it's not always done by the texturemanager, directX does it too. And if it's been done by DirectX and the texturemanager doesn't know about it, we have this bug.
Some explanations would be welcome here.
In short it was causing lot of crashes when MP resumed from S3/S4 on different systems. Haven't been
digging on that issue any closer, rtv might know more.
The original issue is most likely solved in a different way (not 100% sure thou). If not then its still the lesser evil of those two issues we are facing, as crashing MP on S3/S4 resume is a real show stopper for majority of the users.
https://forum.team-mediaportal.com/1-0-rc4-svn-builds-299/mp-crashed-vc-runtime-error-49234/
- Moderator
- #18
Has there been any progress on coming up with a solution for this? Perhaps add it to the Roadmap so its not forgotten.
Has this problem got anything to do with this: https://forum.team-mediaportal.com/streamedmp-301/crashes-basichome-screen-streamedmp-rc4-50221/
Damien
Has this problem got anything to do with this: https://forum.team-mediaportal.com/streamedmp-301/crashes-basichome-screen-streamedmp-rc4-50221/
Damien
- Thread starter
- #19
I keep seeing posts about resume errors in D3D - that's without the patch I made.
On my end, whenever I reinstall a new MP release without or without a SVN release over it, I keep getting those texture errors - after a few video playbacks, textures start to disappear first in TVSeries then everywhere else. I then have to close (sometimes kill the process) MP and restart.
With my patch, everything works fine. Granted, I don't do standby - resumes - but I'm 100% sure the current code does *not* handle texture properly. If there's an event from DirectX telling the app a texture has been released, there's a reason for that, and those should be handled.
Edit: By the way, if someone could move this thread to the bugs thread, it would be better than leaving it here in general dev.
On my end, whenever I reinstall a new MP release without or without a SVN release over it, I keep getting those texture errors - after a few video playbacks, textures start to disappear first in TVSeries then everywhere else. I then have to close (sometimes kill the process) MP and restart.
With my patch, everything works fine. Granted, I don't do standby - resumes - but I'm 100% sure the current code does *not* handle texture properly. If there's an event from DirectX telling the app a texture has been released, there's a reason for that, and those should be handled.
Edit: By the way, if someone could move this thread to the bugs thread, it would be better than leaving it here in general dev.
- Thread starter
- #20
I tried the latest SVN which has tons of fixes UI-wise (great work!)
Still, I keep losing textures after a playback - in moving pictures, I generally lose the background art and the cover art, in the movies default plugin I lose the covert art and in TVSeries I lose a bit of everything, it really depends on the order of allocation I guess.
Anyway, I've seen that there was some new code in GUITextureManager, a textureCacheLookup member. But again I'd like to stress out the fact that until the code actually handles the release events coming from directX, these issues will still crop up. It might not be the case for everyone but directX does release textures when starting a playback.
At least it happens to me on both computers, both running vistax64, one of which has a 8800GTX with 768MB of RAM. playback occurs in exclusive mode.
I still maintain my changes to GUITextureManager & CachedTexture so that when a release from directX occurs it's catched by the code and the cachedtexture knows the texture isn't there anymore. I don't think the fact this causes issues with wakeup from standby on occasions means my code is bad, it's more a side effect textures being properly released I'd guess. Actually I couldn't reproduce a crash on my end when resuming from standby - but I know that doesn't mean anything, after all not everyone is seeing this release issue either.
So, could someone look into the patch I submitted - actually the code was put in SVN at some point - and look into the standby issue again?
Still, I keep losing textures after a playback - in moving pictures, I generally lose the background art and the cover art, in the movies default plugin I lose the covert art and in TVSeries I lose a bit of everything, it really depends on the order of allocation I guess.
Anyway, I've seen that there was some new code in GUITextureManager, a textureCacheLookup member. But again I'd like to stress out the fact that until the code actually handles the release events coming from directX, these issues will still crop up. It might not be the case for everyone but directX does release textures when starting a playback.
At least it happens to me on both computers, both running vistax64, one of which has a 8800GTX with 768MB of RAM. playback occurs in exclusive mode.
I still maintain my changes to GUITextureManager & CachedTexture so that when a release from directX occurs it's catched by the code and the cachedtexture knows the texture isn't there anymore. I don't think the fact this causes issues with wakeup from standby on occasions means my code is bad, it's more a side effect textures being properly released I'd guess. Actually I couldn't reproduce a crash on my end when resuming from standby - but I know that doesn't mean anything, after all not everyone is seeing this release issue either.
So, could someone look into the patch I submitted - actually the code was put in SVN at some point - and look into the standby issue again?