4 questions regarding images handling (Mark?)

Monkey Forums/Monkey Programming/4 questions regarding images handling (Mark?)

ziggy(Posted 2013) [#1]
I have some quick questions regarding Images handling on Monkey and I haven't found any answer anywhere here. I think they are sort of important.

Maybe I've missed some bits in the documentation or here in the forums, but anyway... Let me explain what I think should be a pretty common situation:

In my current game, I need to be sure that level specific graphics are discarded when a level is finished, so I have enought VRam for the next level, so my questions are:

1.- What happens when I Discard an image? Is it removed from the VRAM?

2.- How does this affect grabbed images? Do they get invalid, or the underlying texture is removed from the VRAM only when there are not any more Images of it "alive" in a sort of ref-counting system?

3.- If I don't call the Discard method of an Image instance, and the garbage collector collectes the Image object, assuming there are no more alive Image objects pointing to the same underlying texture, can I assume that this texture will be properly removed from VRAM in all targets, including Java?

It worries me that, given that Java does not provide a destructor in its GC, this images could be kept on the VRAM forever without the coder ever knowing it until the game starts showing rendering glitches. Should I worry about this?

Also:

4.- In case the GC can discard unused textures from collected image objects, can I assume that the GC is fast enough? It worries me if it is too slow to be properly removing textures from the VRAM between level "unload/load next" operations. In other words, if I don't bother to discard Images explicitly and I leave all the work for the GC, what can I expect to happen?

EDIT: Also, why drawing a Discard image produces a runtime error in some targets (HTML5) and just draws nothing in other targets (GLFW). Shouldn't this be a bit more consistent (if possible)?

EDIT2: The Discard method of images that are created as GrabImage from other "parent" images seems to do nothing, you can Discard them, and draw them inmediatly. Is this expected behavior?


Skn3(Posted 2013) [#2]
Well this relates to a question I recently sent to Mark about an issue with switching windowed/fullscreen modes at runtime.

In GLFW if you destroy the window (and in turn GL context) without previously discarding all your images then the images at some level could remain intact. If you later try and render the image albeit in another GL context, this causes images to render improperly. Images will render as white blocks or as corrupted artefacts.

If you just NULL images you can't guarantee that the garbage collector will collect the images in time. With a lot of reading I did, it stated that it can even be upto the graphics card driver to decide if the texture gets freed.

I can't answer for all targets, but from my testing in GLFW if you Discard() images this will invalidate the texture. If you NULL the image handle then Discard() never seems to get called. I don't know if it is doing it internally somewhere, but the destructor and then Discard() never gets called.


Rushino(Posted 2013) [#3]
Mark seem (once again) to do lots of coding right now hehe. He didn't visited the forum for like 3 weeks.


MikeHart(Posted 2013) [#4]
WRONG. Mark visited the forum at least 1 week ago. Hi constantly looks at the bug reports I think. I wouldn't expect to get a response in normal forum posts.


Belimoth(Posted 2013) [#5]
This is relevant to my interests as well.


ziggy(Posted 2013) [#6]
bump!


marksibly(Posted 2013) [#7]
Hi,

> 1.- What happens when I Discard an image? Is it removed from the VRAM?

When you discard an image, the underlying OS 'handle' is closed (GL texture, dx surface etc) which will result in any vram used by the resource being (eventually) released. Any backing store (a version of the image stored in system memory by Mojo in case of 'lost graphics') is also released.

> 2.- How does this affect grabbed images? Do they get invalid, or the underlying texture is removed from the VRAM only when there are not any more Images of it "alive" in a sort of ref-counting system?

Grabbed images maintain a reference to the image they were grabbed from, effectively keeping the source image 'alive'.

> 3.- If I don't call the Discard method of an Image instance, and the garbage collector collectes the Image object, assuming there are no more alive Image objects pointing to the same underlying texture, can I assume that this texture will be properly removed from VRAM in all targets, including Java?

Probably.

Android mojo uses Java 'finalizers' (a kind of destructor) to call Discard, which is what actually releases textures/video mem.

However, finalizers aren't guaranteed to run when garbage is collected - in fact, they're not guaranteed to run at all.

In practice, image textures/memory do appear to get discarded in a timely manner, but I think it may be a good idea to start encouraging people to manually discard images/audio/resources, the same way they should close files.