On Friday, 27 April 2012 at 13:04:32 UTC, Dmitry Olshansky wrote:
Don't. If I still worth anything in GL texture is bound to an opaque uint of sorts. There is no problem copying this number around. There is no point in holding multiple references to 42 ;) Just copy the number.
That's correct. The problem is that if I copy the handle, I don't know when to release the texture. If the application was level based I could keep a list of all used resources for that level, and release them all when the level is destroyed. But an environment is usually quite large, so I need to support streaming. Handling destruction in the destructor end let the GC figure out the rest seemed like a nice solution :P.
Use struct as reference-like type with some alias this magic you may also gain interesting properties. This way you can hide inside a delay-loading scheme of sorts. Say counting usage rates then once resource usage hits a margin you go through the whole list or resources releasing those that are rarely used.
I'm using something commonly known as an entity-component system. There are a lot of dependencies between entities and components, components and components owned by the same or another entity, and who knows what else ;). Using the GC there simplifies things a lot. Components containing reference counted OpenGL resources would still call the destructor on the GC thread. I _could_ modify the system to use ref counting everywhere, but I'm reluctant to do that.
Which reminds me, does the GC actually block all threads while calling the destructors on garbage? I'm far from an expert on GC's, but I believe the mark needs to stop the world, but the sweep can be done concurrently. If the GC thread calls destructors while the other threads aren't waiting, there shouldn't be a problem.
Also let us not forget that each class instance holds monitor object. Even though it's lazying initialized it still occupies extra space.
That's good to keep in mind, but I'm not concerned about memory usage in this case. The size of a texture, vertex buffer or whatever dwarfs the size of the monitor. Total overhead should only be a few kilobytes.
