cc: Various code safety improvements in video compositing code.

cc/layers/video_frame_provider.h

Index: cc/layers/video_frame_provider.h
diff --git a/cc/layers/video_frame_provider.h b/cc/layers/video_frame_provider.h
index 784d951fe52fcef7e8476b96bd910cc00b82f61f..45e6c4110c5364ec5deb36e2e1a7504fcbbf007d 100644
--- a/cc/layers/video_frame_provider.h
+++ b/cc/layers/video_frame_provider.h
@@ -6,6 +6,7 @@
 #define CC_LAYERS_VIDEO_FRAME_PROVIDER_H_
 
 #include "base/memory/ref_counted.h"
+#include "cc/base/cc_export.h"
 
 namespace media {
 class VideoFrame;
@@ -18,11 +19,11 @@ namespace cc {
 // PutCurrentFrame() from the compositor thread. If so, the caller is
 // responsible for making sure Client::DidReceiveFrame() and
 // Client::DidUpdateMatrix() are only called from this same thread.
-class VideoFrameProvider {
+class CC_EXPORT VideoFrameProvider {

[danakj, 2015/03/26 22:38:35]

we don't need to export pure virtual things right?

[sunnyps, 2015/03/27 00:38:46]

I think we do in this case - my CL fails on dll builds. I think it worked before
because we only used an inline function (active_video_layer) of
VideoFrameProviderClientImpl which is a subclass of VideoFrameProvider::Client.
As soon as I changed that to normal function call I got build errors. In the
test which uses active_video_layer there's a static cast from
VideoFrameProvider::Client (which was not exported) to
VideoFrameProviderClientImpl (which was/is exported). Could be that or the 1
million other special cases in C++. :)

  public:
   virtual ~VideoFrameProvider() {}
 
-  class Client {
+  class CC_EXPORT Client {
    public:
     // Provider will call this method to tell the client to stop using it.
     // StopUsingProvider() may be called from any thread. The client should