1
Graphics / Re: Question about Textures and GPU memory
« on: June 04, 2013, 09:37:39 pm »
Well, I don't know why it would suddenly disappear from video memory, but in some game-creation software there was something analogical to RenderTexture, probably, called "surface". Here is an extract from its documentation:
I'm quite new to SFML and have rather vague understanding of what is happening behind the scenes (I'm rather a high-level person, probably; and no, by "high-level" I don't mean how amazing I am), so I can't really tell whether there is room for similar problem as described for "surfaces" above, or textures (and overlying RenderTextures) are handled in a way that properly working computer shouldn't allow problems like that to happen. I figured that if surfaces have problem because of existing in video memory, and textures exist in there as well, then maybe SFML Textures would be as volatile as that program's surfaces.
So yes, can I be rest assured that properly written program won't experience mysterious exodus of textures? And that the reasons of problems with "surfaces' don't apply to Textures? I'm not really into technical details, but I'd like to be sure that my application won't suddenly get all white without any apparent reason, so to speak. ^^"
Quote
First, you should realise that surfaces are "volatile". This means that if the device or window loses focus or is minimised (good examples are when a screensaver comes up in Windows, or on an Android device when the app loses focus due to a call) then the surface may be destroyed. This is because it is stored in the vRam and may be overwritten when the target platform needs that memory for something else which means that you should always have some type of fail-safe code in place, usually with the surface_exists function.
I'm quite new to SFML and have rather vague understanding of what is happening behind the scenes (I'm rather a high-level person, probably; and no, by "high-level" I don't mean how amazing I am), so I can't really tell whether there is room for similar problem as described for "surfaces" above, or textures (and overlying RenderTextures) are handled in a way that properly working computer shouldn't allow problems like that to happen. I figured that if surfaces have problem because of existing in video memory, and textures exist in there as well, then maybe SFML Textures would be as volatile as that program's surfaces.
So yes, can I be rest assured that properly written program won't experience mysterious exodus of textures? And that the reasons of problems with "surfaces' don't apply to Textures? I'm not really into technical details, but I'd like to be sure that my application won't suddenly get all white without any apparent reason, so to speak. ^^"