(Also, add it in WebKit2 layer so that we don't end up calling kdebug_trace millions of times throughout the course of the Design subtest).
Created attachment 411631 [details] Patch
Comment on attachment 411631 [details] Patch EWS failure seems to be due to flaky tests.
Comment on attachment 411631 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=411631&action=review > Source/WTF/wtf/SystemTracing.h:118 > + FlushRemoteImageBufferStart, > + FlushRemoteImageBufferEnd, I'm not too hot on the "flush image buffer" terminology.
Comment on attachment 411631 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=411631&action=review >> Source/WTF/wtf/SystemTracing.h:118 >> + FlushRemoteImageBufferEnd, > > I'm not too hot on the "flush image buffer" terminology. How about "FlushDisplayListStart" and "FlushDisplayListEnd"?
Comment on attachment 411631 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=411631&action=review >>> Source/WTF/wtf/SystemTracing.h:118 >>> + FlushRemoteImageBufferEnd, >> >> I'm not too hot on the "flush image buffer" terminology. > > How about "FlushDisplayListStart" and "FlushDisplayListEnd"? The trace points encompass IPC encoding of the DL, and async dispatch forIPC and displayList.clear(), right? Do we want to track all those, or just the encoding? Or do we really want to track flushDrawingContext/flushDrawingContextAndWaitCommit ?
(In reply to Simon Fraser (smfr) from comment #5) > Comment on attachment 411631 [details] > Patch > > View in context: > https://bugs.webkit.org/attachment.cgi?id=411631&action=review > > >>> Source/WTF/wtf/SystemTracing.h:118 > >>> + FlushRemoteImageBufferEnd, > >> > >> I'm not too hot on the "flush image buffer" terminology. > > > > How about "FlushDisplayListStart" and "FlushDisplayListEnd"? > > The trace points encompass IPC encoding of the DL, and async dispatch forIPC > and displayList.clear(), right? Do we want to track all those, or just the > encoding? Or do we really want to track > flushDrawingContext/flushDrawingContextAndWaitCommit ? My intention was to track flushDrawingContext/flushDrawingContextAndWaitCommit in the remote image buffer case.
Maybe what you have is fine then. Maybe set data1 to 1 in the "and wait" case so we can tell them apart.
(In reply to Simon Fraser (smfr) from comment #7) > Maybe what you have is fine then. Maybe set data1 to 1 in the "and wait" > case so we can tell them apart. Sounds good — changed the second trace scope to `TraceScope tracingScope(FlushRemoteImageBufferStart, FlushRemoteImageBufferEnd, 1);`.
Created attachment 411650 [details] Patch for landing
Committed r268636: <https://trac.webkit.org/changeset/268636> All reviewed patches have been landed. Closing bug and clearing flags on attachment 411650 [details].
<rdar://problem/70402506>