[webkit-dev] Protecting against stale pointers in DrawingBuffer and GraphicsContext3D

[James Robinson]

On Mon, Oct 11, 2010 at 3:15 PM, Chris Marrin <cmarrin at apple.com> wrote:

>
> For accelerated 2D rendering we created a class called DrawingBuffer. This
> encapsulates the accelerated drawing surface (usually in the GPU) and the
> compositing layer used to display that surface on the page. The drawing
> surface (which is called a Framebuffer Object or FBO) is allocated by
> GraphicsContext3D, so DrawingBuffer needs a reference to that. Currently
> this is a weak reference. DrawingBuffer has a ::create() method and you pass
> the GraphicsContext3D to that method.
>
> If you destroy the GraphicsContext3D, DrawingBuffer has a stale pointer. If
> you were to try to destroy the DrawingBuffer it would attempt to use that
> pointer (to destroy its FBO) and crash or worse. Currently we have an
> implicit policy that you should never destroy a GraphicsContext3D before its
> DrawingBuffers are all destroyed. That works fine in the current use case,
> CanvasRenderingContext2D. And we can follow that same policy when in the
> future when we use DrawingBuffer in WebGLRenderingContext.
>
> My concern is that this sort of implicit policy can lead to errors in the
> future when other potential clients of these classes use them. So I posted
> https://bugs.webkit.org/show_bug.cgi?id=47501. In that patch I move the
> creation of DrawingBuffer to the GraphicsContext3D and keep back pointers to
> all the DrawingBuffers allocated so they can be cleaned up when
> GraphicsContext3D is destroyed. In talking to James R. he's concerned this
> adds unnecessary complexity and would rather stick with the implicit policy.
>
> So is this something I should be concerned about, or is an implicit policy
> sufficient in this case?
>

Before somebody suggests it, I think Chris and I are in agreement that
neither GraphicsContext3D nor DrawingBuffer should be RefCounted.  They both
have clear single-ownership semantics.

- James



> -----
> ~Chris
> cmarrin at apple.com
>
>
>
>
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20101011/13934bf5/attachment.html>