On Tue, Jul 30, 2013 at 11:52 PM, Brecht Van Lommel < [email protected]> wrote:
> > but generally it > seems easier to just clear stuff and let Blender create it on demand > rather than to create some wrapper. Especially since the wrapper would > take up memory to store copies of the buffers. > One more thing. This isn't completely true. The data I imagined being registered centrally would be the very same data that Blender would use to recreate it locally (pointers to that data), so it wouldn't be extra data. But realizing that, I also realize there is no reason to store a pointer to the function that creates the resource. Just reset the ID and have the original function create it exactly like it did before. Even if we refactored the code so that all of the resource creation code was separate from the functions that use the resources (good software engineering), there would be no reason to register all of those 'constructors' in a central location. Sometimes I overthink things :-) I was thinking we still need a wrapper for glGen*/glBind*/glDelete*, but that is because I thought that glIs* (as in glIsTexture and friends) were deprecated and/or not available in ES. But it turns out that the glIsFoo functions are available and that they could be used to detect if a resource is dead. Maybe... There is a possibility that resources might get aliased before everything is restored. Crap, I thought I'd figured out a way to not have to create a resource ID wrapper. Since GL tends to give resources the IDs 1, 2, 3 -- it is easy to imagine a situation where you check if 2 is a texture and it succeeds because some other function created a new 2 after CONTEXT_LOST and then you end up using that texture instead of recreating your own. So I think using glIsTexture is out. I don't think there is any way to get out it. There has to be something that keeps track of IDs so they can set back to zero when CONTEXT_LOST occurs. > Brecht. > _______________________________________________ > Bf-committers mailing list > [email protected] > http://lists.blender.org/mailman/listinfo/bf-committers > _______________________________________________ Bf-committers mailing list [email protected] http://lists.blender.org/mailman/listinfo/bf-committers
