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?

-----
~Chris
cmar...@apple.com




_______________________________________________
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Reply via email to