Add metal view, shaders and renderer.

webrtc/sdk/objc/Framework/Headers/WebRTC/RTCMTLRenderer.h

+/*
+ *  Copyright 2017 The WebRTC project authors. All Rights Reserved.
+ *
+ *  Use of this source code is governed by a BSD-style license
+ *  that can be found in the LICENSE file in the root of the source
+ *  tree. An additional intellectual property rights grant can be found
+ *  in the file PATENTS.  All contributing project authors may
+ *  be found in the AUTHORS file in the root of the source tree.
+ */
+
+#import <Foundation/Foundation.h>
+#import "WebRTC/RTCVideoRenderer.h"
+
+@class MTKView;
+
+NS_ASSUME_NONNULL_BEGIN
+RTC_EXPORT
+/**
+ * Render class that uses Metal to render RTCVideoFrame in an instance of MTKView.
+ */
+@protocol RTCMTLRenderer<RTCVideoRenderer>

[tkchin_webrtc, 2017/02/10 23:32:10]

RTCMTLRendere <RTC

+
+- (instancetype)initWithView:(__weak __kindof MTKView *)view;

[tkchin_webrtc, 2017/02/10 23:32:10]

Don't put ctors in protocol decls, overly restrictive, and you can't make any
guarantees on how subclasses choose to implement it.

MTKView behaves like GLKView of the past

Any reason not to create a composed view instead? Where you have an
RTCMTLVideoView that sets up a MTKView?

[daniela-webrtc, 2017/02/13 12:32:06]

I see your point of this being restrictive and makes the API opinionated. 
The reason why I wanted to inject the MTKView as early as possible (in the
`init`) was to have ensure control over the view setup (the setup of the view is
tied to the MTLDevice object in the renderer). So it's a tradeoff between
flexibility and reliability.

[tkchin_webrtc, 2017/02/14 00:23:56]

Sure, but that can be a base abstract class. In this particular case, it's odd
to me to say that a Metal renderer must have a setup() method, and that it must
take a kind of MTKView. This really seems to me like a concrete implementation
of a kind of video renderer.

In general, I don't think it is good practice for most objects to have a ctor
that takes in a UIView. A UIView may or may not be actually in the view
hierarchy at any given moment of time. In this rendering case, the view should
be the one that decides if it wants to render or not, since it knows about when
it actually draws and layouts.

+
+/**
+ * Sets up the renderer.
+ *
+ * If the method returns NO it signifies the renderer is unable to perform proper setup and
+ * it's responsibility of the caller to perform all necessary clean up after this point.
+ * Unexpected behavior can happen if the cleanup doesn't happen and the renderer continues
+ * accepting RTCVideoRenderer callbacks.
+ */
+- (BOOL)setup;
+
+@end
+
+NS_ASSUME_NONNULL_END