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

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Mon Apr 4 14:06:06 PDT 2011


--- Comment #8 from Stephen White <senorblanco at chromium.org>  2011-04-04 14:06:06 PST ---
(From update of attachment 88115)
View in context: https://bugs.webkit.org/attachment.cgi?id=88115&action=review

>>>>> Source/WebKit/chromium/src/GraphicsContext3DChromium.cpp:621
>>>>> +    }
>>>> It seems weird to short-circuit the normal error handling, but only for this function and only for chromium.  What do you think, Ken?
>>>> This check is wrong if level != 0, I believe.
>>> The problem is that the calling code relies on this texImage2D call to return false if something went wrong, and it would be far too expensive to call glGetError after each texImage2D call. This explicit shortcut is a concession to make large layers work properly. Alternatively, we could do some queries at the call site (which is rarely called) to see whether the texture was allocated correctly. It's a problem that glGetTexLevelParameteriv isn't available in GLES2, but maybe there's another query that could be made to see if the texture object was successfully allocated.
>> You're right that it's a little different to add the error handling here.  I wanted the routine to respect the comments in GraphicsContext3DInternal.h   (http://www.google.com/codesearch/p?vert=chromium#OAMlx_jo-ck/src/third_party/WebKit/Source/WebKit/chromium/src/GraphicsContext3DInternal.h&l=190)
>> I believe it should work for levels other than 0.
> Can we just make the caller (DrawingBuffer stuff here) glGet() the texture bounds and check that itself?  If the texture object creation fails for any other reason then this check won't do anything.
> We query and cache the max texture bounds in some places currently, IIRC

KBR:  I'm not too worried about a call to getIntegerv(), given that GraphicsContext3D::texImage2DResourceSafe() further up the stack is doing an enormous malloc() and memset() on every texture allocation (we should really doing a glClear() on the bound FBO instead, but that's another bug).  I agree with jamesr:  putting the check in DrawingBuffer would fix the bug, and skip both the malloc() and memset() for large layers.  (BTW, we already do such a check via getIntegerv on every texture creation in platform/graphics/Texture.cpp.)

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

More information about the webkit-unassigned mailing list