[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 #24 from Jeff Timanus <twiz at chromium.org>  2011-04-07 15:25:40 PST ---
(In reply to comment #23)
> (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] [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.
> 
> Aha, that's what I ran into before (just forgot where it was).
> 
> > 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.
> > 
> > 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.
> 
> I think the constructor param is a good idea.  Since this would require chrome-side changes (as would the in-process change above), perhaps we should split the work into just fixing the layout test, and address the performance issues in a subsequent patch (after the chrome changes).
> 
> My preference would be to land something between revs 2 and 3 of this patch (including the DrawingBuffer::create returning NULL change that jamesr suggested, but excluding the ResourceSafeNoClear changes).  This would fix the layout test, and we can look at improving the performance once the chrome-side changes have landed.
> 
> Does that sound good?

Yes, that sounds very good.  I was hoping it would be an easy change to remove the heavy initialization code, but after all of this discussion, it is obvious that it is a separate issue to address.

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