Bug 217853 – Add system trace points for flushing remote image buffers

• Component: WebKit2
• Status: RESOLVED FIXED

[Wenson Hsieh]

(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).

[Wenson Hsieh]

Created attachment 411631 [details]
Patch

[Wenson Hsieh]

Comment on attachment 411631 [details]
Patch

EWS failure seems to be due to flaky tests.

[Simon Fraser (smfr)]

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.

[Wenson Hsieh]

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"?

[Simon Fraser (smfr)]

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 ?

[Wenson Hsieh]

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

[Simon Fraser (smfr)]

Maybe what you have is fine then. Maybe set data1 to 1 in the "and wait" case so we can tell them apart.

[Wenson Hsieh]

(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);`.

[Wenson Hsieh]

Created attachment 411650 [details]
Patch for landing

[EWS]

Committed r268636: <https://trac.webkit.org/changeset/268636>

All reviewed patches have been landed. Closing bug and clearing flags on attachment 411650 [details].

[Radar WebKit Bug Importer]

<rdar://problem/70402506>