then again, maybe we could just clear it out of the surface bundle, since it's a unique_ptr.  adding an explicit destroy to a unique_ptr'd object would be a little strange.

Clearing the pointer and surface from the bundle sgtm. But what is responsible for doing that if MCVD is destroyed and only the images hold the bundle?

Seems like we need a new wrapper class that holds a strong ref to a bundle and, listens to SurfaceDestroyed and deletes its bundle. Then CodecImages hold one of these.

the bundle can register itself with AndroidOverlay::AddSurfaceDestroyedCallback, and delete the overlay unique_ptr from itself.

then again, that might be confusing for MCVD, so maybe each codec image should register itself, and respond by dropping its ref to the bundle.  that makes more sense.

Hmm, the second one makes sense. But there are some complicated threading concerns :( I'm beginning to think we should 

MCVD is created in the Media Service which is a mojo service that's started and destroyed on demand. When it's started it's given a thread to run on, and when it's done the thread is destroyed. It's possible to hold a ServiceContextRef to extend the lifetime of the thread, which is what MCVD holds as a member so it can live beyond its owner and drain and delete itself. 

So if MCVD goes away but an AO is kept alive by the images, the thread might be stopped. And MojoAndroidOverlay won't receive calls from the browser side.

I'm starting to think we should make the MediaService thread lazily created but never stopped, maybe with an eye towards being able to stop it eventually.

Maybe the best option is to bind MojoAndroidOverlays on a task scheduler sequence and make them threadsafe.

i'm not sure about how "task scheduler sequence" works, so i'm ignoring it until i go learn more.

otherwise, i think that overlays should be bound to the gpu main thread, not the mcvd thread.  the only accesses in mcvd aren't sensitive to latency.  the SOP work should avoid a thread hop if possible.

allocation via the chooser is already mostly via callbacks anyway, that could thread hop if MCVD wants.

deallocation would currently drop the surface bundle on the MCVD thread, but we could teach the bundle to post a DeleteSoon to main, i suppose.  that's ugly.

i'll go learn about c#4 .