[Bf-committers] EGL_CONTEXT_LOST and GL_ARB_create_context_robustness

[Jason Wilkins]

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 ;-)