[Oilpan] Migrate classes under module/webgl onto oilpan heap

Source/modules/webgl/WebGLVertexArrayObjectBase.cpp

Index: Source/modules/webgl/WebGLVertexArrayObjectBase.cpp
diff --git a/Source/modules/webgl/WebGLVertexArrayObjectBase.cpp b/Source/modules/webgl/WebGLVertexArrayObjectBase.cpp
index 5f3d0c2ae6d61eff2c86d4bd3f2caebb5dcc2a0c..49ba53c46834c260a0e85b7c2109d7c872456fc2 100644
--- a/Source/modules/webgl/WebGLVertexArrayObjectBase.cpp
+++ b/Source/modules/webgl/WebGLVertexArrayObjectBase.cpp
@@ -15,9 +15,7 @@ WebGLVertexArrayObjectBase::WebGLVertexArrayObjectBase(WebGLRenderingContextBase
     , m_object(0)
     , m_type(type)
     , m_hasEverBeenBound(false)
-#if ENABLE(OILPAN)
     , m_destructionInProgress(false)
-#endif
     , m_boundElementArrayBuffer(nullptr)
 {
     m_vertexAttribState.reserveCapacity(ctx->maxVertexAttribs());
@@ -33,9 +31,7 @@ WebGLVertexArrayObjectBase::WebGLVertexArrayObjectBase(WebGLRenderingContextBase
 
 WebGLVertexArrayObjectBase::~WebGLVertexArrayObjectBase()
 {
-#if ENABLE(OILPAN)
     m_destructionInProgress = true;

[haraken, 2015/08/04 00:06:52]

Instead of introducing another flag like m_destructionInProgress, I'd prefer
just clearing out m_boundElementArrayBuffer and m_vertexAttribState here.

c.f., see what WebGLRenderbuffer::~WebGLRenderbuffer() is doing.

[peria, 2015/08/04 09:10:26]

will do in another CL.
http://crbug.com/516613

-#endif
 
     // Delete the platform framebuffer resource. Explicit detachment
     // is for the benefit of Oilpan, where this vertex array object
@@ -71,7 +67,6 @@ void WebGLVertexArrayObjectBase::deleteObjectImpl(WebGraphicsContext3D* context3
         break;
     }
 
-#if ENABLE(OILPAN)
     // These m_boundElementArrayBuffer and m_vertexAttribState heap
     // objects must not be accessed during destruction in the oilpan
     // build. They could have been already finalized. The finalizers
@@ -79,12 +74,9 @@ void WebGLVertexArrayObjectBase::deleteObjectImpl(WebGraphicsContext3D* context3
     // detachment.
     if (!m_destructionInProgress)
         dispatchDetached(context3d);

[haraken, 2015/08/04 00:06:52]

Sigbjorn: Do we still need to call dispatchDetached here? In oilpan, the
lifetime of a WebGL object is explicitly managed by the WebGL object itself
calling WebGL::detachAndDeleteObject(). So I'm wondering if we can completely
remove WebGLObject::m_attachmentCount. If we can remove it, we can remove
WebGLObject::onDetached(). Then we can remove dispatchDetached().

(Either way, we can handle this in a follow-up CL.)

[Ken Russell (switch to Gerrit), 2015/08/04 00:34:11]

One note about this. In order to maintain uniform behavior across many vendors'
OpenGL drivers, it has been found necessary in the past to defer destruction of
certain OpenGL objects. For example, if a shader is attached to a program and
the user calls deleteShader against it, we need to delay the destruction of the
shader until the program is deleted. Same for renderbuffers and textures that
are attached to framebuffer objects.

It's possible that we could reevaluate the need to do this work at the Blink
layer -- it may be well handled by Chromium's command buffer at this point. We
should discuss this more. However, in the spirit of minimizing the amount of
changes in this already-large CL, yes, this should be considered for a follow-on
CL.

[haraken, 2015/08/04 00:47:05]

Thanks for the context. I now understand why the onDetached calls are needed.

(Another option might be to remove the onDetached calls and keep the underlying
platform object alive until the WebGLObject gets destructed (the underlying
platform object is destructed in WebGLObject's destructor). That said, it will
prolong the platform object lifetime too much.)

[sof, 2015/08/04 06:20:45]

Good point, I think we can remove the Oilpan specific part (i.e., remove
m_destructionInProgress) due to the partial ordering of finalizers that we've
now got here.

[peria, 2015/08/04 09:10:26]

Acknowledged.
http://crbug.com/516613

-#else
-    dispatchDetached(context3d);
-#endif
 }
 
-void WebGLVertexArrayObjectBase::setElementArrayBuffer(PassRefPtrWillBeRawPtr<WebGLBuffer> buffer)
+void WebGLVertexArrayObjectBase::setElementArrayBuffer(WebGLBuffer* buffer)
 {
     if (buffer)
         buffer->onAttached();
@@ -98,12 +90,12 @@ WebGLVertexArrayObjectBase::VertexAttribState* WebGLVertexArrayObjectBase::getVe
     ASSERT(index < context()->maxVertexAttribs());
     // Lazily create the vertex attribute states.
     for (size_t i = m_vertexAttribState.size(); i <= index; i++)
-        m_vertexAttribState.append(adoptPtrWillBeNoop(new VertexAttribState()));
+        m_vertexAttribState.append(new VertexAttribState);
     return m_vertexAttribState[index].get();
 }
 
 void WebGLVertexArrayObjectBase::setVertexAttribState(
-    GLuint index, GLsizei bytesPerElement, GLint size, GLenum type, GLboolean normalized, GLsizei stride, GLintptr offset, PassRefPtrWillBeRawPtr<WebGLBuffer> buffer)
+    GLuint index, GLsizei bytesPerElement, GLint size, GLenum type, GLboolean normalized, GLsizei stride, GLintptr offset, WebGLBuffer* buffer)
 {
     GLsizei validatedStride = stride ? stride : bytesPerElement;
     VertexAttribState* state = getVertexAttribState(index);
@@ -123,7 +115,7 @@ void WebGLVertexArrayObjectBase::setVertexAttribState(
     state->offset = offset;
 }
 
-void WebGLVertexArrayObjectBase::unbindBuffer(PassRefPtrWillBeRawPtr<WebGLBuffer> buffer)
+void WebGLVertexArrayObjectBase::unbindBuffer(WebGLBuffer* buffer)
 {
     if (m_boundElementArrayBuffer == buffer) {
         m_boundElementArrayBuffer->onDetached(context()->webContext());
@@ -131,7 +123,7 @@ void WebGLVertexArrayObjectBase::unbindBuffer(PassRefPtrWillBeRawPtr<WebGLBuffer
     }
 
     for (size_t i = 0; i < m_vertexAttribState.size(); ++i) {
-        VertexAttribState* state = m_vertexAttribState[i].get();
+        VertexAttribState* state = m_vertexAttribState[i];
         if (state->bufferBinding == buffer) {
             buffer->onDetached(context()->webContext());
             state->bufferBinding = nullptr;