* Environment variables are not user-friendly, but I don't want to promote this
to a capture option since it's so niche.
* In future perhaps it will be feasible to support selecting an arbitrary API
to capture, or even capturing multiple APIs simultaneously - though with GLES-
on-GL that will be quite difficult.
* On windows we can load libEGL which then loads opengl32.dll, so we ensure that
opengl32.dll is loaded first at startup rather than have it appear last-minute
in a recursive call.
* Likewise, when using EGL we forcibly forget all GL function pointers and fetch
them through eglGetProcAddress, rather than having a mix-and-match dispatch
table.
* Requires either driver support (EXT_create_context_es2_profile) or a GLES
emulating library like ANGLE.
* Note however that ANGLE doesn't at this point meet the minspec for replay, so
it can only be captured from.
* Render passes and framebuffers can have as many attachments as desired, and
just use a small subset in each subpass. We shouldn't add an artificial limit
without good reason.
* When selecting a marker region, the more intuitive search is to find children
of the marker first before searching onwards, even if the 'current event' is
at the end of the marker region.
* Sometimes a GLES implementation can refuse to copy back the 'native'
format/type, most commonly if you want to read back from a GL_RGB texture it
might require you to readback GL_RGBA.
* We handle this by just reading back the requested format in this case, and
then copying only RGB tightly into the output buffer.
* Unfortunately it seems like sometimes in GL when creating an GL_RGB
internalformat texture you can copy from another GL_RGB internalformat
texture. Other times you can't.
* In particular the difference can just be the 'type' parameter passed when
passing initial data, GL_UNSIGNED_BYTE vs eGL_UNSIGNED_SHORT_5_6_5
* We treat this as a 'soft' hint, so if it's not present we fall back to the old
path.
* In particular it wasn't added until GLES 3.1, and we need it during capture to
determine the uniforms and other things, so we emulate the subset of queries
that we need ourselves.
* This is only to be used to make a temporary context to share with. We make
sure to use the same visual/config as the parent context to ensure it will
successfully share.
* We need to hack around GLES, as it somehow added only part of the original
extension - non-arrayed textures. So we conceptually split up the extension
into two, and treat the real extension as a superset.
* This function is not available until 3.1 so we can't rely on being able to use
it - even if we get a valid function pointer for it.
* We emulate it by storing the data up front and allowing the emulation layer
access to our texture info to look it up. It's a bit roundabout but it works.
baldurk