Bug 89693 – Web Inspector: timeline instrumentation for screen update

• Status: RESOLVED
• Resolution: INVALID
• Component: Web Inspector (Deprecated)

[Andrey Kosyakov]

This adds a new timeline record and instrumentation interface for "Update Screen" events, designating time spent pushing rendered bitmaps to the screen.

[Andrey Kosyakov]

Created attachment 148894 [details]
Patch

[WebKit Review Bot]

Please wait for approval from [e-mail], [e-mail], [e-mail], [e-mail] or [e-mail] before submitting, as this patch contains changes to the Chromium public API. See also https://trac.webkit.org/wiki/ChromiumWebKitAPI.

[WebKit Review Bot]

Comment on attachment 148894 [details]
Patch

Attachment 148894 [details] did not pass chromium-ews (chromium-xvfb):
Output: http://queues.webkit.org/results/13036301

New failing tests:
inspector/timeline/timeline-enum-stability.html

[WebKit Review Bot]

Created attachment 148948 [details]
Archive of layout-test-results from ec2-cr-linux-01

The attached test failures were seen while running run-webkit-tests on the chromium-ews.
Bot: ec2-cr-linux-01  Port: <class 'webkitpy.common.config.ports.ChromiumXVFBPort'>  Platform: Linux-2.6.35-28-virtual-x86_64-with-Ubuntu-10.10-maverick

[Pavel Feldman]

Comment on attachment 148894 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=148894&action=review

> Source/WebCore/ChangeLog:8
> +        Added TimelineRecordType::UpdateScreen and plumbed it all the way through to InspectorInstrumentation.

What does UpdateScreen mean?

> Source/WebCore/inspector/front-end/TimelineModel.js:54
> +    UpdateScreen: "UpdateScreen",

Make sure you fix the test for this?

[James Robinson]

I'm also curious about what "screen update" means and how it relates to our various other instrumentation points.

[Andrey Kosyakov]

(In reply to comment #6)
> I'm also curious about what "screen update" means and how it relates to our various other instrumentation points.

That was meant as a time we spend in the renderer waiting for browser to flush the composited bitmap to the screen -- basically, time between DidInitiatePaint() and DidFlushPaint(). I reckon this is somewhat difficult to express in terms that would make sense to a user. Besides, this is an async event, so rather than visualizing the entire duration of event, we probably want to just show the time the beginning of the next frame was delayed by waiting for DidFlushPaint.
The bottom line -- scratch that implementation, I'll think a bit and have another approach.

[Brian Burg]

Closing as invalid, as this bug pertains to the old inspector UI and/or its tests.
Please file a new bug (https://www.webkit.org/new-inspector-bug) if the bug/feature/issue is still relevant to WebKit trunk.