tracking down high memory usage in skiptool

[pastro]

Didn't appear to change the memory usage. PF usage keeps going up and process memory goes up to about 250M until it drops back to 35M or so. At that point the system performance is very sluggish.

Essentially aren't we creating new GBPVRUiElements each time the getimage callback occurs? Seems like the I would need to keep track of the previous GBPVRUiElement and dispose of that. It's a local variable to me so I don't get how I would dispose of it later but I guess I'll experiment around.

[pastro]

In pastro's case if he (or Wiz framework) is ending up creating a new GBPVRUiElement for each bitmap video frame he is trying to display, then the element should be dispose when he creates the new one (since the old one is no longer required). The reason this is required is because the element has a handle to an underlying direct3d texture which is unmanaged and wont be garbage collected.

.

I think this is probably the trouble.
I am creating a new GBPVRUIElement whenever I return a new bitmap. This occurs all the time.

Are you saying I need to have a variable in my object that will contain all of the GBPVRUIElement that I return to the framework and then on the next render callback I should dispose of these via: PluginHelperFactory[SIZE=2].getPluginHelper().DisposeResources(disposeList);[/SIZE]

I suppose I would only store the element if it was the GBPVRUIElement that contains one of the changing bitmaps and then dispose of it the next time around if that bitmap is being changed.
Does that make sense?

[sub]

Are you saying I need to have a variable in my object that will contain all of the GBPVRUIElement that I return to the framework and then on the next render callback I should dispose of these via: PluginHelperFactory.getPluginHelper().DisposeResources(disposeList);

Only if you're no longer going to be using the GBPVRUIElement object. If you've got GBPVRUIElement objects that represent objects on the screen that are reused over and over on every call to GetRenderList() then you dont need to dispose of these.

I suppose I would only store the element if it was the GBPVRUIElement that contains one of the changing bitmaps and then dispose of it the next time around if that bitmap is being changed.

Yes, or you can reuse the GBPVRUIElement and just set the forceRefresh=true if the picture has changed. This will force the framework to discard the cached version of that image, and reload it from the new image contained in the object.

[pastro]

Yes, or you can reuse the GBPVRUIElement and just set the forceRefresh=true if the picture has changed. This will force the framework to discard the cached version of that image, and reload it from the new image contained in the object.

I'll give that a shot. Thanks.

[pastro]

I went through the renderlist and found the the GBPVRUIElement that has the changing bitmaps and set forcerefresh=true, but that didn't help. I still see the PF's climbing up and up.
I guess I don't really get when the cached copy would get used anyway. I am changing the bitmap and previously forcerefresh was false, I was still getting new images. What determines whether a cached copy is used or the new one?

[sub]

I guess I don't really get when the cached copy would get used anyway. I am changing the bitmap and previously forcerefresh was false, I was still getting new images. What determines whether a cached copy is used or the new one?

The cached copy is only created when you doing things on the PC, not on an MVP. Basically on its way to being displayed on the screen a Direct3D texture is created, same size as the image contained in your GBPVRUIElement, and is loaded from that image. When you pass that GBPVRUIElement object to be displayed by Direct3D, it checks if the texture needs to be recreated (forceRefresh=true or image size has changed or is a new GBPVRUiElement), otherwise it just tells your video card to display that texture at a certain location on the screen. It is slow to create these textures, which is why GB-PVR keeps a cached version when it can, allowing for fast animations etc.

None of this happens when you're do the same thing on the MVP. So I'd check whether you're seeing the same problem with the memory creeping up on the MVP. If you are, then its most likely to do with your own memory mangement in your plugin (loading image files, garbage collection etc).

[pastro]

The cached copy is only created when you doing things on the PC, not on an MVP. Basically on its way to being displayed on the screen a Direct3D texture is created, same size as the image contained in your GBPVRUIElement, and is loaded from that image. When you pass that GBPVRUIElement object to be displayed by Direct3D, it checks if the texture needs to be recreated (forceRefresh=true or image size has changed or is a new GBPVRUiElement), otherwise it just tells your video card to display that texture at a certain location on the screen. It is slow to create these textures, which is why GB-PVR keeps a cached version when it can, allowing for fast animations etc.

Sorry in advance for the stupid questions...
So if I return a button with changed text, how does it know it is different? The size is the same only the bitmap data is different. Does it do a compare?

[sub]

So if I return a button with changed text, how does it know it is different?

It knows because you've set forceRefresh=true. It doesnt look at the contents of the image to compare... that would be way slow.

[JavaWiz]

Only if you're no longer going to be using the GBPVRUIElement object. If you've got GBPVRUIElement objects that represent objects on the screen that are reused over and over on every call to GetRenderList() then you dont need to dispose of these.

Yes, or you can reuse the GBPVRUIElement and just set the forceRefresh=true if the picture has changed. This will force the framework to discard the cached version of that image, and reload it from the new image contained in the object.

The WizUiList was basically cloned from sub's UiList object, and uses the same caching scheme that he uses. If the cache fills, it reuses the oldest element and sets forceRefresh to true.

[sub]

From his previous posts in this thread, I dont think he is talking about the list. Its probably some of the other items he is showing on his popup (see screenshots here http://gbpvr.com/pmwiki/pmwiki.php/Plugin/BurnDVDX2/)