I suspect this is easy to fix if we block the UI thread for the initial compositing and the entire duration of the window animation the way Cocoa does, but we probably don't want to do that.

We currently do block the UI thread, but only for window-modal sheets. (Since we use the native sheet animation and there's no way to prevent it completely starving Chrome's UI thread).

I got curious and did some tracing today. To put some numbers on it, there's about 45 milliseconds from the start of the event to show the bubble and the buffer swap happening.

~10ms is typesetting (the lion's share of Layout)
~10ms is mystery latency that might be easy to avoid
~5ms is painting
~5ms is compositing
~10ms is talking to the GPU

fixing that mystery latency should take it down below the 30fps threshold (~33ms).

But it doesn't look like we're wasting CPU cycles. So unless this _feels_ slow, there's really no point optimizing it since it's so far below human perception.

Deleted: trace_show_add_bookmark_zerocopy.json.gz 257 KB

trace_show_add_bookmark_zerocopy.json.gz 257 KB Download

Deleted: show_bookmark_bubble_zero_copy.png 353 KB

	show_bookmark_bubble_zero_copy.png 353 KB View Download

Doesn't macOS run at 60fps :)? I always hear the ChromeOS graphics folks talking about a 16ms deadline, too. Still, I agree that this doesn't seem bad. It does *feel* slow to me. Not every time I open a bubble, but most of the times. I'm not sure where it is.

I don't see mouse up events in chrome://tracing. Do you know where I can find them?

60fps is good for animations where you need a frame between each vsync, but mouse events don't coordinate with vsync. It's not worth the effort to optimise that far - even if you got it down to 16ms, you'd never take advantage of it unless the mouse event came in *right* after a vsync. Missing a frame or two (or three) isn't noticeable when things don't animate - (and even 24fps is fine for movies :p). 

For the mouseup -- if it's on the browser window, it's only going through Cocoa, not views, and the tracing there is pretty incomplete. I see 

Title	BrowserCrApplication::sendEvent
Category	toplevel
User Friendly Category	other
Start	
5,059.040 ms
Wall Duration	
0.112 ms
CPU Duration	
0.111 ms

which is probably the mouseUp. Nothing below it.

Assigning this to sdy@, who is going to be the MacViews Perf person, but I think this bug is probably still Pri-3 and M-X.

sdy: let's target a fix for this (if we intend to do anything concrete) at M68.

The Profile Switcher has been a MacViews window since m64, and it's pretty snappy after I addressed stuff in  Issue 789118 .

A outstanding blocker on that is Issue 788597, which might notch up performance a bit more.

See also a doc I put together on performance here - https://docs.google.com/document/d/1t7MdfWLdTFbVVIrxTZJxYuy9VzzTFFWZHgOE3OH-q5A/edit - there's some more low-hanging fruit

** Bulk Edit **

FYI: Starting 04/13 M68 will be in canary, M68 Dev promotion will be on 04/26.

Pls mark the bug as fixed if CL is landed in trunk and nothing else is pending. Thank you.

Triage: Upgrading to P1

macviews triage: sdy: where is this? is it better?