Not ready for review.

Not ready for review.

Added extension allowing client to get ANGLE's D3D device.

Chromium gets ANGLE's D3D to read the device caps and to determine whether it is D3D9Ex.

Now we have a third need for the device: to decode video using DXVA2.

D3D has a way of coordinating the sharing of a device and saving restoring state through IDirect3DDeviceManager9.

http://msdn.microsoft.com/en-us/library/windows/desktop/ms696198(v=VS.85).aspx

I exposed the interface as an EGL extension. This is idea is still a little half baked. There are some things I don't like about it.

The client can only make certain assumptions about the device's state when it is locked. Context::applyRenderTarget is called on the context if there is one current, so all that state should be valid. In fact, the intention is that the client can assume that whatever ID3DDevice9::GetRenderTarget returns can be rendered to directly and whatever changes are made will stick. It also ensures that the scene is started.

I didn't expose a flag to make lockDevice block since we don't support multiple threads and blocking, if it ever happened, would be deadlock if I understand the semantics right. Maybe I should add a placeholder argument so we can change it in the future without modifying the signature.

The extension assumes one device for EGL display, which is what we have today in order to support share groups. In the case where we went with one device per share group, this extension would need to take the context as an argument. In fact it would probably want to be a GLES2 extension rather than an EGL extension.

I considered other approaches. I could just add an extension to return the device directly and have the client promise not to mess with it too much, watch for context lost, etc. Using the existing D3D mechanism for sharing seemed better.

Since we mostly want this for video decoding, I considered adding an extension to allow the decoding to be done by ANGLE, actually piping the encoded video in somehow. That seemed like I might end up essentially implementing OpenMAX on top of DXVA2, which would be neat, but more work than is strictly necessary.