[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Public WebGL] Proposal for the WEBGL_debug extension



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
option.

> 
> 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 public_webgl@khronos.org.
To unsubscribe, send an email to majordomo@khronos.org with
the following command in the body of your email:
unsubscribe public_webgl
-----------------------------------------------------------