[Public WebGL] Proposal for the WEBGL_debug extension

Emmanuel Gil Peyrot [email protected]
Thu Oct 1 10:18:56 PDT 2015

On Wed, Sep 30, 2015 at 11:06:32PM -0700, Kenneth Russell wrote:
> Could you describe in more detail how you've used your prototype
> implementation of this extension and how it's improved your debugging
> workflow?

The main reason I started working on this extension was integration
with existing GLES debugging tools, namely apitrace in my case.

This allows seamless debugging of the WebGL application, the web
browser, and the graphics driver, either while they are running or
post-mortem, which can be very useful especially on embedded platforms
where a full-blown debugger or even a JS console isn’t always an

> There are many simple JavaScript frameworks like webgl-debug.js (
> https://github.com/KhronosGroup/WebGLDeveloperTools ) that wrap the
> WebGLRenderingContext, calling getError() after each call, and
> throwing an exception if an error occurred, which can be caught in the
> browser's devtools debugger.

There are two big issues with this approach:
- Only errors can be found that way, there is no possibility for the
  driver or browser to present performances issues, warnings about
  undefined behaviours allowed by the specification, nor for the
  application to tell the debugger about whatever it wants.
- They reduce performances by making many asynchronous things
  synchronous, which can hide some race condition bugs (I have
  encountered that issue), and can’t usually be enabled/disabled on a
  per-case basis.

> -Ken

Emmanuel Gil Peyrot
Collabora Ltd.

You are currently subscribed to [email protected]
To unsubscribe, send an email to [email protected] with
the following command in the body of your email:
unsubscribe public_webgl

More information about the public_webgl mailing list