[MPlayer-dev-eng] [PATCH] DR support for vo_corevideo

[Zongyao Qu]

> 2) Since there is neither double-buffering nor a way to wait for the
> application to finish processing for shared_buffer, you can't use
> direct rendering with it, it would cause a significant risk of tearing
> or even worse artefacts due to the decoder already drawing the next
> frame into it before the application finished process.

lacking of double buffering is a big problem, so I made a patch for
myself.

https://github.com/niltsh/mplayer-for-
MPlayerX/commit/a8e911716d0362500f3455f30f2d7b2129164e6b

But in this patch, the Protocol for buffer sharing is not compatible
with previous, so I'm afraid it will make many mplayer frontend
developer angry.

I think only committing the double buffering part is better.

Also I just want to point out that even with single buffering, image
tearing could be avoided as easy as copying the image once 
in the remote process, when it is called by [mplayerosxProto render], 
which is located in flip_page. Because [mplayerosxProto render] 
runs synchronized with remote process, said by Apple,

https://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/
DistrObjects/DistrObjects.html#//apple_ref/doc/uid/10000102i

Of course, single buffering has really poor performance.