If Blender is to run on mobile devices and OpenGL ES then it needs to be able to handle the fact that it's OpenGL context may need to be recreated from scratch.
Background: OpenGL normally requires that a copy of every resource be held by the OpenGL driver in the event that the OS has to destroy them due to various events. This could be caused by changing the display resolution or going into standby mode. This can be wasteful because it means textures are held in main memory as well as video card memory. I think Direct3D has always provided for the loss of the graphics card device. The D3D equivalent of SwapBuffers is usually where you'd check to see if the device is still there. However, OpenGL drivers take care of this themselves by automatically restoring their copy of your application's resources. This makes Direct3D more difficult on the programmer (I've seen production games that simply give up if they lose the context, as if it was an exception and not an event you have to plan for!), but it also gives you flexibility on where you backup your resources. You can keep them on disk or regenerate them procedurally. OpenGL really just has one solution, keep them in memory. I hope that lays out the situation accurately. Solution: A 'robust' context is one that restores itself and until the GL_ARB_create_context_robustness extension you had no choice but to create a 'robust' context. OpenGL ES on the other hand, since it is targeted as memory constrained devices that must conserve power has never given you the option to create a robust context. There are several things that need to be done to handle this in Blender, 1) There must be a baseline OpenGL state that all functions can assume before they execute. They must restore this state when they complete (although some state, like the current color, which is almost always changed, can be assumed to be in some random state and left as is after completion). With this assumption it wouldn't matter if the context were recreated because the baseline will be restored. 2) No data structure can contain a raw resource identifier, because that resource may disappear and become invalid at any time. All resources need to centrally registered along with a callback function and the data needed to restore them. If the context is lost then this will be caught at the next SwapBuffers and all of the callbacks will be executed, restoring the resources in a newly minted context. Resources include texture objects, vertex array objects, vertex buffer objects, frame buffer objects, etc. Anything with a Gen/Delete function pair. Interestingly enough, Blender does a lot of drawing with DrawPixels, and those functions would actually keep working just fine after a context loss (but are deprecated and also are not a part of ES...) Since the registered resources can change after being created this means all of the functions for each resource will need to be wrapped so that the cached copy of the resource can be updated. I almost forgot about shaders... Those are probably the most complex resource. In the case of something like a VBO, there is very little to remember about it in order to recreate it, especially if it is WRITE_ONLY. However, shaders are the result of several steps involving compilation and linking. So, while simple resources can be encapsulated rather directly, shaders probably need to be wrapped at a higher level to keep the complexity down. I always feel like I'm going out on a limb when talking to you smart people, so I'll stop here before one of you gets out your saw ;-) _______________________________________________ Bf-committers mailing list [email protected] http://lists.blender.org/mailman/listinfo/bf-committers
