debugging DesktopGL in test_shell

32 views
Skip to first unread message

Marshall Greenblatt

unread,
Oct 22, 2010, 11:42:13 AM10/22/10
to Kenneth Russell, chromium-dev
Hi Kenneth,

I'm attempting to debug why WebGL isn't displaying when using kGLImplementationDesktopGL in test_shell. As far as I can tell the shared PbufferGLContext objects are being set up correctly (no errors are being written to the log file, and all of the gl calls are succeeding).  So, I'm wondering if perhaps either (a) the buffers aren't being sized correctly or (b) the contents aren't being transferred to the screen. I've been looking at the code for a while now but I can't identify exactly where these two actions should be occurring. Any hints that you could provide on how to proceed would be greatly appreciated.

Thanks,
Marshall

Marshall Greenblatt

unread,
Oct 22, 2010, 12:52:23 PM10/22/10
to Kenneth Russell, chromium-dev
On Fri, Oct 22, 2010 at 11:42 AM, Marshall Greenblatt <magree...@gmail.com> wrote:
Hi Kenneth,

I'm attempting to debug why WebGL isn't displaying when using kGLImplementationDesktopGL in test_shell. As far as I can tell the shared PbufferGLContext objects are being set up correctly (no errors are being written to the log file, and all of the gl calls are succeeding).  So, I'm wondering if perhaps either (a) the buffers aren't being sized correctly or (b) the contents aren't being transferred to the screen. I've been looking at the code for a while now but I can't identify exactly where these two actions should be occurring. Any hints that you could provide on how to proceed would be greatly appreciated.

Another point of information:

WebGraphicsContext3DDefaultImpl::readPixels() is being called on paint with the correct size. However, the call that this method makes to glReadPixels() is returning GL_INVALID_OPERATION.

 

Thanks,
Marshall

Marshall Greenblatt

unread,
Oct 22, 2010, 9:20:24 PM10/22/10
to Kenneth Russell, chromium-dev

So it seems that the chromium WebKit implementation (--in-process-webgl) of both desktop (--use-gl=desktop) and egl (--use-gl=egl) are broken in chromium as well as test_shell on Windows at revision 63396.

Is the intent to remove WebGraphicsContext3DDefaultImpl and related classes from the code base completely?  If so, would it be possible to re-factor WebGraphicsContext3DCommandBufferImpl and related classes such that the bulk of the implementation can live outside of /chrome?

 

 

Thanks,
Marshall


Kenneth Russell

unread,
Oct 25, 2010, 9:00:18 PM10/25/10
to Marshall Greenblatt, chromium-dev
Hi Marshall,

Sorry for the delay in replying. I was swamped trying to upgrade the
version of Mesa we use for automated testing.

It looks like there are a few different reasons --in-process-webgl is
broken. I've committed http://codereview.chromium.org/4127002 fixing
one of them; with this change, the combination of --in-process-webgl
--use-gl=desktop should be working in Chrome on Windows. Just
--in-process-gl (which runs on top of ANGLE by default on Windows) is
still broken due to https://bugs.webkit.org/show_bug.cgi?id=48282 .
Finally, --in-process-webgl is broken on Linux due to
http://crbug.com/55152 (see the crash in
IA__gdk_x11_get_default_xdisplay); I do not know why this is happening
at this point.

Note that you almost certainly also have to specify
--disable-accelerated-compositing.

The plan is to leave WebGraphicsContext3DDefaultImpl in place, and use
it for testing in DumpRenderTree. That's the configuration where it
will receive the most testing. The combination of compositor + WebGL
will work in DRT.

-Ken

On Fri, Oct 22, 2010 at 6:20 PM, Marshall Greenblatt

Marshall Greenblatt

unread,
Oct 26, 2010, 11:29:25 AM10/26/10
to Kenneth Russell, chromium-dev
On Mon, Oct 25, 2010 at 9:00 PM, Kenneth Russell <k...@chromium.org> wrote:
Hi Marshall,

Sorry for the delay in replying. I was swamped trying to upgrade the
version of Mesa we use for automated testing.

It looks like there are a few different reasons --in-process-webgl is
broken. I've committed http://codereview.chromium.org/4127002 fixing
one of them; with this change, the combination of --in-process-webgl
--use-gl=desktop should be working in Chrome on Windows. Just
--in-process-gl (which runs on top of ANGLE by default on Windows) is
still broken due to https://bugs.webkit.org/show_bug.cgi?id=48282 .
Finally, --in-process-webgl is broken on Linux due to
http://crbug.com/55152 (see the crash in
IA__gdk_x11_get_default_xdisplay); I do not know why this is happening
at this point.

Note that you almost certainly also have to specify
--disable-accelerated-compositing.

Thanks a bunch for looking into this Ken.  The following combination of flags now works for me:

--in-process-webgl --use-gl=desktop --disable-accelerated-compositing


The plan is to leave WebGraphicsContext3DDefaultImpl in place, and use
it for testing in DumpRenderTree. That's the configuration where it
will receive the most testing. The combination of compositor + WebGL
will work in DRT.

Is there a bug that I can follow in order to be notified when accelerated compositing and WebGL play nice together?

Thanks,
Marshall
 

Kenneth Russell

unread,
Oct 26, 2010, 4:51:35 PM10/26/10
to Marshall Greenblatt, chromium-dev

I've re-tested test_shell on Linux with
--enable-accelerated-compositing --enable-webgl --use-gl=desktop and
the combination of these flags is working at least on Linux; it should
be on the other platforms as well. Hopefully this addresses your need.
There is no bug filed for making --in-process-webgl work with the
compositor in Chromium itself.

-Ken

Marshall Greenblatt

unread,
Oct 26, 2010, 7:33:27 PM10/26/10
to Kenneth Russell, chromium-dev

test_shell on Windows 7 64bit at revision 63938 seems to be having V8 problems -- it's crashing on www.google.com.  Accelerated compositing and WebGL appear non-functional no matter what flags are used (perhaps related to the V8 issue).

test_shell on Windows 7 64bit at revision 63396 using "--enable-accelerated-compositing --enable-webgl --use-gl=desktop" works with accelerated compositing [1] but causes WebGL [2] to fail. Using just "--enable-webgl --use-gl=desktop" causes WebGL to work at that revision.

[1] http://webkit.org/blog-files/3d-transforms/poster-circle.html
[2] http://learningwebgl.com/lessons/lesson01/index.html
 

Kenneth Russell

unread,
Oct 26, 2010, 9:20:03 PM10/26/10
to Marshall Greenblatt, chromium-dev

It doesn't look like a V8 problem. It looks like incorrect usage of
the V8 API by code recently changed in WebKit. I've filed
http://crbug.com/60864 to track this. Do you have Visual Studio? If
so, it would be most helpful if you would file bug reports with
similar detail.

> test_shell on Windows 7 64bit at revision 63396 using
> "--enable-accelerated-compositing --enable-webgl --use-gl=desktop" works
> with accelerated compositing [1] but causes WebGL [2] to fail. Using just
> "--enable-webgl --use-gl=desktop" causes WebGL to work at that revision.
>
> [1] http://webkit.org/blog-files/3d-transforms/poster-circle.html
> [2] http://learningwebgl.com/lessons/lesson01/index.html

We'll need to wait for TOT test_shell to work to investigate this
further. Once it is no longer crashing on http://www.google.com/,
please file any bugs with Area-Internals, Internals-Graphics,
Feature-GPU and CC me on the reports.

-Ken

Marshall Greenblatt

unread,
Oct 26, 2010, 9:42:42 PM10/26/10
to Kenneth Russell, chromium-dev

Sure thing. That was on my to-do list for tomorrow.

>
>> test_shell on Windows 7 64bit at revision 63396 using
>> "--enable-accelerated-compositing --enable-webgl --use-gl=desktop" works
>> with accelerated compositing [1] but causes WebGL [2] to fail. Using just
>> "--enable-webgl --use-gl=desktop" causes WebGL to work at that revision.
>>
>> [1] http://webkit.org/blog-files/3d-transforms/poster-circle.html
>> [2] http://learningwebgl.com/lessons/lesson01/index.html
>
> We'll need to wait for TOT test_shell to work to investigate this
> further. Once it is no longer crashing on http://www.google.com/,
> please file any bugs with Area-Internals, Internals-Graphics,
> Feature-GPU and CC me on the reports.

Will do. When I'm not sure of the correct behavior I like to ask
before filing bugs -- hense this thread :-)

Marshall Greenblatt

unread,
Oct 27, 2010, 10:25:51 AM10/27/10
to Kenneth Russell, chromium-dev

Kenneth Russell

unread,
Oct 27, 2010, 5:57:22 PM10/27/10
to Marshall Greenblatt, chromium-dev
On Wed, Oct 27, 2010 at 7:25 AM, Marshall Greenblatt

Thanks. Fixed upstream in WebKit under
https://bugs.webkit.org/show_bug.cgi?id=48470 .

-Ken

Reply all
Reply to author
Forward
0 new messages