When moving a window, the renderers are flooded with PageMsg_UpdateWindowScreenRect messages
Reported by
mitchman...@gmail.com,
Apr 3 2018
|
||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/65.0.3325.183 Safari/537.36 Vivaldi/1.96.1137.1 Steps to reproduce the problem: 1. Open multiple tabs, 20 or so to easier see the performance impact. 2. Drag the title bar of the browser window and move it around on the screen. 3. Watch the flood of PageMsg_UpdateWindowScreenRect IPC messages (using chrome://tracing or similar) and observe the high CPU usage for the main UI process. What is the expected behavior? It should implement a MSG ACK method like it is done for the ViewMsg_UpdateScreenRect to avoid this unnecessary performance hit of sending and processing a constant message flood that is repeated for every tabs open. What went wrong? PageMsg_UpdateWindowScreenRect is have a similar msg send <->ACK procedure as for other often sent messages. Did this work before? No Chrome version: 65.0.3325.183 Channel: stable OS Version: 10.0 Flash Version:
,
May 11 2018
mitchman1411@ -- Could you please confirm the option selected by you while recording the trace using chrome://tracing. Could you please share a screencast of the issue. In which section are your tracking the value of 'PageMsg_UpdateWindowScreenRect'. Tried all the options in recording a trace. But, the mentioned element is not found. You can also verify by updating your Chrome to #66.0.3359.170 Thanks!
,
May 17 2018
Hm, I'm not seeing this on Linux. mitchman1411@, could you attach a trace here? chaopeng@, you have a Win laptop, can you try and see if you can repro.
,
May 17 2018
1. I saw CPU high when dragging and moving the tab. (4% Idle, 30% dragging) It should be expected seen we doing continuously hittest when dragging and moving. And it can down to 4% after stop dragging and moving. 2. I do not seeing PageMsg_UpdateWindowScreenRect or ViewMsg_UpdateScreenRect in tracing with all selected.
,
May 18 2018
I see it when selecting trace for only ipc messages, but you will need to zoom in quite a bit to get to the messages itself. However, when testing with Canary, the overhead in processing these messages seems to be far less than earlier version. It's still quite an unnecessary overhead with many tabs open that can be avoided with a ACK mechanism as is implemented with the sister message ViewMsg_UpdateScreenRect. I'm attaching the zoomed in view I see in Canary.
,
May 18 2018
(I filed this bug with a different email than my work address)
,
May 18 2018
The screenshot seems like an acceptable amount of work to me (<50us per message). I'm not really familiar with these IPCs, what's the ACK mechanism and how does it help avoid an IPC? An ACK is itself an IPC and it doesn't seem like we're doing any work here so I'm not sure how we can save anything.
,
Jul 3
Sorry for the late reply, I've been away. I guess it's more visible with many tabs open. msg/ack will ensure only one message is being sent at the time, the next message will not be sent until an ack has been received from the renderer. With many tabs, this will reduce the IPC significantly.
,
Jul 4
,
Nov 26
*** UI Mass Triage*** Unable to reproduce from TE end.As per dev comments adding labels for expert review.Thanks! |
||||||||||
►
Sign in to add a comment |
||||||||||
Comment 1 by krajshree@chromium.org
, Apr 3 2018