[Webkit-unassigned] [Bug 57768] Accelerated Canvas2D path failing when constructing large canvases.

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=57768





--- Comment #22 from Zhenyao Mo <zmo at google.com>  2011-04-07 15:04:41 PST ---
(In reply to comment #21)
> (In reply to comment #19)
> > (In reply to comment #17)
> > > (In reply to comment #14)
> > > > (In reply to comment #12)
> > > > > (From update of attachment 88657 [details] [details] [details] [details] [details])
> > > > > View in context: https://bugs.webkit.org/attachment.cgi?id=88657&action=review
> > > > > 
> > > > > > Source/WebCore/platform/graphics/gpu/DrawingBuffer.cpp:205
> > > > > > +        m_context->texImage2DResourceSafeNoClear(GraphicsContext3D::TEXTURE_2D, 0, internalColorFormat, m_size.width(), m_size.height(), 0, colorFormat, GraphicsContext3D::UNSIGNED_BYTE);
> > > > > 
> > > > > I would like to change this call to a simple texImage2D with a NULL data parameter.  Can someone please confirm if this will work?
> > > > 
> > > > This will break the tests running with in-process gl.
> > > 
> > > I think the reason they failed before was that I was relying on the FBO textures being cleared automatically in the in-process version (in the same way they were in the command buffers).
> > > 
> > > If we call glClear() the first time the DrawingBuffer is bound, these tests should pass.
> > 
> > Also, in the in-process gl, we emit an INVALID_VALUE if passed in data is NULL.  You have to remove that before calling texImage2D with NULL.
> 
> Mo's right; I forgot about that check in webgraphicscontext3d_in_process_impl.cc in the Chromium tree.
> 
> I talked with senorblanco about this topic earlier, and suggested we could have another argument to GraphicsContext3D::create which would indicate whether the caller is trusted (compositor, canvas2d) or untrusted (webgl). In the former case we could disable some of these checks.

We could have a light-weight command buffer where all the sanity checking and other stuff are behind the DEBUG flag, and it simply passes commands down to underlying drivers.

> 
> twiz, i'm not sure what would be the fastest path forward for you, but feel free to make whatever changes you need to in order to make this most efficient, including adding new entry points. I do think that the constructor idea might be the best long-term direction, though.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.