Convert most remaining resources to use the API/thunk system. The significant

ppapi/thunk/ppb_context_3d_api.h

Index: ppapi/thunk/ppb_context_3d_api.h
===================================================================
--- ppapi/thunk/ppb_context_3d_api.h	(revision 0)
+++ ppapi/thunk/ppb_context_3d_api.h	(revision 0)
@@ -0,0 +1,53 @@
+// Copyright (c) 2011 The Chromium Authors. All rights reserved.
+// Use of this source code is governed by a BSD-style license that can be
+// found in the LICENSE file.
+
+#ifndef PPAPI_THUNK_PPB_CONTEXT_3D_API_H_
+#define PPAPI_THUNK_PPB_CONTEXT_3D_API_H_
+
+#include "ppapi/c/dev/ppb_context_3d_dev.h"
+#include "ppapi/c/dev/ppb_context_3d_trusted_dev.h"
+#include "ppapi/c/dev/ppb_gles_chromium_texture_mapping_dev.h"
+
+namespace ppapi {
+namespace thunk {
+
+class PPB_Context3D_API {
+ public:
+  // Context3D.
+  virtual int32_t GetAttrib(int32_t attribute, int32_t* value) = 0;
+  virtual int32_t BindSurfaces(PP_Resource draw, PP_Resource read) = 0;
+  virtual int32_t GetBoundSurfaces(PP_Resource* draw, PP_Resource* read) = 0;
+
+  // Context3DTrusted.
+  virtual PP_Bool InitializeTrusted(int32_t size) = 0;
+  virtual PP_Bool GetRingBuffer(int* shm_handle,
+                                uint32_t* shm_size) = 0;
+  virtual PP_Context3DTrustedState GetState() = 0;
+  virtual PP_Bool Flush(int32_t put_offset) = 0;
+  virtual PP_Context3DTrustedState FlushSync(int32_t put_offset) = 0;
+  virtual int32_t CreateTransferBuffer(uint32_t size) = 0;
+  virtual PP_Bool DestroyTransferBuffer(int32_t id) = 0;
+  virtual PP_Bool GetTransferBuffer(int32_t id,
+                                    int* shm_handle,
+                                    uint32_t* shm_size) = 0;
+  virtual PP_Context3DTrustedState FlushSyncFast(int32_t put_offset,
+                                                 int32_t last_known_get) = 0;
+
+  // GLESChromiumTextureMapping.

[piman, 2011/06/20 20:26:14]

Why are these piggy-backing on the PPB_Context3D_API ? They're a lot more like
all the other GL calls (in PPB_OpenGLES2_Dev) than the above... We should be
consistent and either put the GL calls here, or move these 2 calls out and
handle them the same way as the GL calls.

[brettw, 2011/06/20 21:37:11]

Everything "should" be like this and go through the thunk layer. The advantage
of the thunk layer is that it saves you from having to implement the resource
conversion multiple times, and allows you to write object-oriented code in the
impl and the proxy.

But if I were to do that for the GL calls, that would be >100 virtual functions
in each of these places which can't be autogenerated. I can do things, like
maybe autogenerate a header file with a define for the declaration of all of
these functions, and then use that in both the proxy and the impl, then
autogenerate another file to forward these from the Context to the gles_impl.

It seemed less complexity overall to treat the autogenerated GL functions as
special and bypass the thunk layer.

+  virtual void* MapTexSubImage2DCHROMIUM(GLenum target,
+                                         GLint level,
+                                         GLint xoffset,
+                                         GLint yoffset,
+                                         GLsizei width,
+                                         GLsizei height,
+                                         GLenum format,
+                                         GLenum type,
+                                         GLenum access) = 0;
+  virtual void UnmapTexSubImage2DCHROMIUM(const void* mem) = 0;
+};
+
+}  // namespace thunk
+}  // namespace ppapi
+
+#endif  // PPAPI_THUNK_PPB_CONTEXT_3D_API_H_
Property changes on: ppapi/thunk/ppb_context_3d_api.h
___________________________________________________________________
Added: svn:eol-style
   + LF