Add events with custom timestamps and thread id to PPAPI dev tracing interface.

ppapi/api/dev/ppb_trace_event_dev.idl

 /* Copyright (c) 2012 The Chromium Authors. All rights reserved.
  * Use of this source code is governed by a BSD-style license that can be
  * found in the LICENSE file.
  */
 
 /**
  * This file defines the <code>PPB_Trace_Event</code> interface. It is meant
  * to be used in plugins as the API that trace macros from trace_event.h use.
  */
 
 label Chrome {
-  M25 = 0.1
+  M25 = 0.1,
+  M29 = 0.2
 };
 
 interface PPB_Trace_Event_Dev {
   /**
    * Gets a pointer to a character for identifying a category name in the
    * tracing system as well as for being able to early exit in client-side
    * tracing code.
    *
    * NB: This mem_t return value should technically be const, but return values
    * for Pepper IDL of mem_t type are not const.  The same is true for the arg
@@ skipping 13 matching lines @@
       [in] mem_t category_enabled,
       [in] cstr_t name,
       [in] uint64_t id,
       [in] uint32_t num_args,
       [in, size_as=num_args] str_t[] arg_names,
       [in, size_as=num_args] uint8_t[] arg_types,
       [in, size_as=num_args] uint64_t[] arg_values,
       [in] uint8_t flags);
 
   /**
+   * Adds a trace event to the platform tracing system. This function call is

[elijahtaylor1, 2013/06/24 21:04:18]

This comment is identical to the previous one.  Can you elaborate on why this is
different and why it might be used on the backend of trace_events.h macros
instead of the vanilla one above?

[grosse, 2013/06/24 23:16:46]

Done.

+   * usually the result of a TRACE_* macro from trace_event.h when tracing and
+   * the category of the particular trace are enabled. It is not advisable to
+   * call this function on its own; it is really only meant to be used by the
+   * trace macros.
+   */
+  [version=0.2]
+  void AddTraceEventWithThreadIdAndTimestamp(
+      [in] int8_t phase,
+      [in] mem_t category_enabled,
+      [in] cstr_t name,
+      [in] uint64_t id,
+      [in] int32_t thread_id,
+      [in] int64_t timestamp,

[dmichael (off chromium), 2013/06/24 17:43:42]

Do you plan to ever pass anything other than Now() here? If not, maybe we should
just omit that param, leave out the Now() function, and have the proxy-side
implementation apply it instead.

[It's a little confusing/weird to have a Now() function on this interface; we
already provide time ticks in another way on PPB_Core. I'd like to avoid adding
a new way.]

[grosse, 2013/06/24 23:16:46]

We want to make sure that we're using the same clock as the event tracing
interface.

[dmichael (off chromium), 2013/06/25 21:01:57]

PPB_Core::GetTimeTicks also uses base::TimeTicks::Now(). The only difference is
it converts to PP_TimeTicks (which is a double). Any precision loss will be
minor and won't really matter for trace events. You should just use
PPB_Core::GetTimeTicks and get rid of Now().

+      [in] uint32_t num_args,
+      [in, size_as=num_args] str_t[] arg_names,
+      [in, size_as=num_args] uint8_t[] arg_types,
+      [in, size_as=num_args] uint64_t[] arg_values,
+      [in] uint8_t flags);
+
+  /**
+   * Get the current clock value, suitable for adding trace events.

[elijahtaylor1, 2013/06/24 21:04:18]

It isn't clear from this comment why it is useful to include this in the trace
event API.  Can you elaborate here why it is useful over ordinary time functions
you might have access to?  Or why you need to pass in a timestamp in the first
place?

[grosse, 2013/06/24 23:16:46]

Done.

+   */
+  [version=0.2]
+  int64_t Now();
+
+  /**
    * Sets the thread name of the calling thread in the tracing system so it will
    * show up properly in chrome://tracing.
    */
   void SetThreadName([in] cstr_t thread_name);
 };