liberato@ asked: "can direct composition overlays use a different d3d device?  does it have to use the angle device?"

It could, but that would complicate a lot of other things.

However, the direct composition surface handle that we create is meant for sharing across devices and processes so that the swap chain can be created on a different device or process than where the direct composition tree lives.

This would mean the decoder could present to the swap chain directly on its thread.  Initiating the present from the main thread would probably involve posting a task to the decoder thread.  Do we expect it to be busy?  Note: direct composition commits are not synchronized with swap chain presents anyway so it should work even if the present happens after commit.

The decoder will also need to have a fallback mode for when we switch to GL compositing e.g. something like CopyingGLImageDXGI where it copies from a non-shared resource to a shared resource for already decoded images and uses the shared resource for future decodes.

> Do we expect it to be busy?

i don't know.  on one hand, whatever work is on the decoder's thread would have delayed composition anyway.  on the other hand, thread hops tend not to work that way in practice.

it sounds like a promising direction.

> CopyingGLImageDXGI

that one might be tricky, since it'll be called from the wrong thread when the (synchronous) copy needs to happen.

then again, maybe that's not so bad. i forgot that device contexts don't have thread affinity, so we just need a lock.