Tal's picture

Does GameWindow delete textures automatically?

Does OpenTK GameWindow delete all textures in exit automatically?
Becouse I got an error when I delete a texture on a destructor...
So I wanna be sure becouse when I delete a texture not in a destructor it's working fine(in Dispose(true)).
So is it?


Comments

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
the Fiddler's picture

The answer is no and yes:

  • No, OpenTK doesn't manage OpenGL resources itself. This task falls to you. :)
  • Yes, all OpenGL resources die along with the OpenGL context when you call GameWindow.Dispose(). (Your GPU drivers clean up everything whenever a context dies.)

For simple applications, calling GameWindow.Dispose() should be enough. For larger applications, you might need to cook up some sort of resource manager.

Note that .Net finalizers run on a background thread that doesn't have access to OpenGL. This is why you get errors when you try to clean up resources from finalizers. Read the GraphicsContext documentation for more information.

Tal's picture

Thanks for replying!
So if I don't dispose it in "larger applications"(hypothetical), I will not need to use finalizers somehow? Because you said the GPU does it for me, yes?
I also looked up in the source code, and found that as you said none of OpenTK class clean the resource in the GraphicsContext when disposed or dead(finalizers).
Ans one more think that bothered me when I looked up in the source code:
Is it so importent(long tasks in the locked code) to use SyncRoot in the GraphicsContext instead of using a spin lock?
Sorry that I bother you with so much questions...

the Fiddler's picture

To clarify:

  • by "simple" I refer to applications that can allocate everything on startup and delete everything on shutdown
  • by "complex" I refer applications that cannot afford to do that (i.e. they have to stream resources dynamically or load/unload resources on level changes)

In the first case, you can get away with leaving cleanup to the drivers. In the second case you will have to implement some form of dynamic resource management.

Note that you cannot use finalizers to clean up OpenGL resources, because the finalization thread doesn't have access to OpenGL.

OpenTK does not keep track of your OpenGL resources, you have to do this yourself if necessary. However, OpenGL resources are (or should be) cleaned up by your drivers/OS when a GraphicsContext is disposed (i.e. you won't get a memory leak when the application exits - but this won't help you if you have more resources than can fit in memory at runtime.)

What long-running tasks would be better suited to spinlocks rather than lock()? (Aren't spinlocks better suited to short-running tasks anyway?)

Tal's picture

Thank you very much for your full answer!
I have already understood that the proper way is to call Dispose for every thing(which happendes in complex apps) and delete them manualy.
"OpenGL resources are (or should be) cleaned up by your drivers/OS when a GraphicsContext is disposed(or dead), this is the answer I was looking for.
And finally - I guess you right and it should be a exclusive lock. I didn't realize that this tasks is so long(they seems to be short in first look :-) ).
And again - thank you very much!