WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED FIXED
Bug 77238
Add Plumbing to get graphics error messages to JS Console
https://bugs.webkit.org/show_bug.cgi?id=77238
Summary
Add Plumbing to get graphics error messages to JS Console
Gregg Tavares
Reported
2012-01-27 13:02:38 PST
Add Plumming to get graphics error messages to JS Console
Attachments
Patch
(13.75 KB, patch)
2012-01-27 13:03 PST
,
Gregg Tavares
no flags
Details
Formatted Diff
Diff
Patch
(14.33 KB, patch)
2012-01-27 13:55 PST
,
Gregg Tavares
no flags
Details
Formatted Diff
Diff
Patch
(14.35 KB, patch)
2012-01-27 18:21 PST
,
Gregg Tavares
no flags
Details
Formatted Diff
Diff
Show Obsolete
(2)
View All
Add attachment
proposed patch, testcase, etc.
Gregg Tavares
Comment 1
2012-01-27 13:03:47 PST
Created
attachment 124356
[details]
Patch
Gregg Tavares
Comment 2
2012-01-27 13:05:27 PST
Hope this is good.
WebKit Review Bot
Comment 3
2012-01-27 13:07:32 PST
Please wait for approval from
fishd@chromium.org
before submitting because this patch contains changes to the Chromium public API.
Gregg Tavares
Comment 4
2012-01-27 13:55:44 PST
Created
attachment 124363
[details]
Patch
Darin Fisher (:fishd, Google)
Comment 5
2012-01-27 15:31:48 PST
Comment on
attachment 124363
[details]
Patch View in context:
https://bugs.webkit.org/attachment.cgi?id=124363&action=review
> Source/WebKit/chromium/public/platform/WebGraphicsContext3D.h:121 > + class WebGraphicsErrorMessageCallback {
WebKit already has a way to write to the console. Why do you need this? See DOMWindow::console().
Kenneth Russell
Comment 6
2012-01-27 15:40:26 PST
Comment on
attachment 124363
[details]
Patch View in context:
https://bugs.webkit.org/attachment.cgi?id=124363&action=review
>> Source/WebKit/chromium/public/platform/WebGraphicsContext3D.h:121 >> + class WebGraphicsErrorMessageCallback { > > WebKit already has a way to write to the console. Why do you need this? > See DOMWindow::console().
The intent is to allow deeper layers of Chromium's graphics stack to call back up and print detailed error messages to the console. Is there way to do this entirely on the Chromium side? How could we get from the WebGraphicsContext3DCommandBufferImpl to a WebFrame?
Darin Fisher (:fishd, Google)
Comment 7
2012-01-27 16:11:54 PST
Comment on
attachment 124363
[details]
Patch View in context:
https://bugs.webkit.org/attachment.cgi?id=124363&action=review
>>> Source/WebKit/chromium/public/platform/WebGraphicsContext3D.h:121 >>> + class WebGraphicsErrorMessageCallback { >> >> WebKit already has a way to write to the console. Why do you need this? >> See DOMWindow::console(). > > The intent is to allow deeper layers of Chromium's graphics stack to call back up and print detailed error messages to the console. > > Is there way to do this entirely on the Chromium side? How could we get from the WebGraphicsContext3DCommandBufferImpl to a WebFrame?
Oh, sorry, I had the interfaces inverted in my head. This makes sense now. Yes, plumbing through here makes more sense than trying to grovel around in the renderer for the associated WebFrame.
Kenneth Russell
Comment 8
2012-01-27 18:01:10 PST
Comment on
attachment 124363
[details]
Patch View in context:
https://bugs.webkit.org/attachment.cgi?id=124363&action=review
Looks fine to me. Could you please add a little more detail to the bug report about the goal of this patch? Thanks.
> Source/WebCore/ChangeLog:8 > + No new tests. (OOPS!)
You'll need to remove this line in order for the commit queue to process the patch.
Gregg Tavares
Comment 9
2012-01-27 18:21:47 PST
Created
attachment 124417
[details]
Patch
Gregg Tavares
Comment 10
2012-01-27 18:36:28 PST
This patch is to allow the graphics system, which may be running in another process, the get errors back up to the WebGLRenderingContext so it can send those errors to the JS console. Since the errors are generated asynchronously we need way to get them back into the class that called them. There is one issue in that we can't currently associate which line of JavaScript issued the offending command but at least this way the developer will see the errors. The implementation does return a 32bit id for each error so if we wanted to, in the future, we could add a function, GraphicsContext3D::setDebugId(int id) or similar after which all commands that generate errors would return that id. We could then associate those ids with some javascript data to lookup the correct lines. I suspect doing that would be somewhat slow so it would probably be best disabled by default and only enabled through some kind of developer facing option. In the meantime, at least with these errors plummed through devs can see their program is doing something wrong. Most errors also have a function name associated with them which probably makes them pretty easy to find even without the line number.
Kenneth Russell
Comment 11
2012-01-30 17:44:39 PST
Comment on
attachment 124417
[details]
Patch Looks great. r=me
WebKit Review Bot
Comment 12
2012-01-30 19:11:06 PST
Comment on
attachment 124417
[details]
Patch Clearing flags on attachment: 124417 Committed
r106320
: <
http://trac.webkit.org/changeset/106320
>
WebKit Review Bot
Comment 13
2012-01-30 19:11:11 PST
All reviewed patches have been landed. Closing bug.
Darin Adler
Comment 14
2012-01-31 09:39:09 PST
I can’t help thinking that “plumming” is referring to some sort of drive-by fruiting.
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug