[Dark Shell] Win: Slow menu drawing at startup

[gruehle]

Steps to repro

1. Launch Sprint 30 on Windows.
2. Select Debug > New Brackets Window and watch how fast the menu is drawn in the new window
3. Now launch Sprint 31 and do the same thing

Results

When the second window opens, you can clearly see the menus being drawn one at a time.

[gruehle]

Medium priority for now. I'm running in a VM, which could be contributing to the slowdown. Someone who isn't running a VM should check the performance differences between Sprint 30 and Sprint 31.

Also, this could be a CEF issue instead of a Dark Shell issue, since we pulled in a new CEF for Sprint 31.

[redmunds]

I am seeing this on Native Windows 7 on my Lenovo W510. It's not always noticeable, so it may be dependent on what else is running on my computer.

[RaymondLim]

I'm seeing it on my Win 7 (Lenovo W510), not only for secondary windows, but also for the main window.

[redmunds]

I meant to say I'm seeing it on main window.

[peterflynn]

I see it on the main window as well -- changing title to reflect that

[peterflynn]

Do we know if this slows down startup overall? I can't imagine that the code in DefaultMenus normally takes that long to run. Is it just the native painting side that's slow, but it's parallelized with other startups tasks continuing on the JS side? Or does the JS side actually get stuck waiting between each call in DefaultMenus?

[peterflynn]

Nominating for Sprint 34 to at least investigate a bit

[redmunds]

I'm seeing a general slowdown during startup on Windows. Slow menu drawing maybe just be a symptom.

[redmunds]

FBNC back to @gruehle

[gruehle]

The menu drawing is definitely better, but startup time is still pretty slow. Should we have a new bug on the slow startup time?