| Commit message (Collapse) | Author | Age |
|
|
|
|
|
|
|
|
|
|
| |
Chrome's got a test scenario where setting the user-supplied tracer is racing with a concurrent use of the default tracer.
BUG=chromium:437044
No public API changes.
TBR=reed@google.com
Review URL: https://codereview.chromium.org/1099123002
|
|
|
|
|
|
|
|
|
|
|
| |
BUG=skia:
R=bsalomon@google.com
Author: humper@google.com
Review URL: https://codereview.chromium.org/136753013
git-svn-id: http://skia.googlecode.com/svn/trunk@13287 2bbb7eff-a529-9590-31e7-b0007b416f81
|
|
|
|
|
|
|
|
|
|
|
| |
BUG=skia:
R=bsalomon@google.com
Author: humper@google.com
Review URL: https://codereview.chromium.org/145973011
git-svn-id: http://skia.googlecode.com/svn/trunk@13283 2bbb7eff-a529-9590-31e7-b0007b416f81
|
|
|
|
| |
git-svn-id: http://skia.googlecode.com/svn/trunk@13258 2bbb7eff-a529-9590-31e7-b0007b416f81
|
|
This patch includes a modified version of Chrome's trace_event.h, which provides
tracing macros that can easily integrate into the about://tracing framework.
Currently the macros link to a default implementation of the (narrow) tracing
class SkDefaultEventTracer which does nothing; next step will be to have Chrome
subclass the SkEventTracer with a shim that bolts Skia's trace events to its own,
allowing Skia's trace events to show up in about://tracing.
I've verified that this file builds properly, and when I added a simple scoped
TRACE_EVENT0 to SkCanvas::drawRect, along with some debug prints in the NOP
implementation of tracing, I saw what I expected printed to the screen.
BUG=skia:
R=nduca@chromium.org, reed@google.com, mtklein@google.com, bsalomon@google.com
Author: humper@google.com
Review URL: https://codereview.chromium.org/149563004
git-svn-id: http://skia.googlecode.com/svn/trunk@13256 2bbb7eff-a529-9590-31e7-b0007b416f81
|