WIN: UI shakes and flickers a lot when resizing Brackets window by dragging

[dalcala]

Description:
On Windows, the UI shakes & flickers a lot when you resize the Brackets window by dragging the top edge or the left edge of the Brackets window. The problem is much less noticeable when dragging the bottom edge or right edge. It's really noticeable if you have multiple inline color editors open. I tried making a Jing screen capture video, but the jiggle isn't picked up in the video. Maybe related to #1741?

keywords: jumpy, choppy, jiggles, jumps

Repro using Brackets Sprint 29 on Win 7. UTR on Mac 10.8.

Repro steps:

1. Open a css file and invoke inline color editor in multiple places. Also happens with an html file.
2. Resize the Brackets window by dragging the top edge or the left edge of the Brackets window.

Actual results:
UI shakes and flickers a lot.

Expected results:
UI doesn't shake and flicker a lot.

Workaround:
Deal with cosmetic issue.

[gruehle]

Reviewed. Medium priority to @JeffryBooher

[rajeshsegu]

We could throttle the call of the resize handler once every 100ms. ( http://underscorejs.org/#throttle ). Today in a given second its fired close to 100+ times which is waste of DOM cycles. Meanwhile, the flicker is also related to CodeMirror resizing their code very often, we can sync them both at once is 200ms, which I think is reasonable.

[redmunds]

@dalcala I remember this being really bad. I'm not sure what changed, but this seems way better to me now on Win7. Are you still seeing the problem?

[peterflynn]

Removing top/left from title since you can see this with any resize (and same with #5258)

[JeffryBooher]

Adding CEF/TRACKING -- although this could be solved in shell or more efficient DOM

[JeffryBooher]

WOW. This got incredibly worse with CEF 2171

[JeffryBooher]

https://code.google.com/p/chromiumembedded/issues/detail?id=1448

[peterflynn]

@JeffryBooher I'm not seeing a regression here with CEF 2171. On Win 7, it actually seems to respond to resizing more smoothly and quickly than CEF 1547.

[RaymondLim]

@peterflynn In CEF 2171 I can see the flickering in the area covered by the border, title bar and the menu bar, but not in the side bar or the editor area.

[peterflynn]

I busted out the trusty high-speed camera for a quick test.

• When resizing the window smaller, there's repaint fighting in both versions: it appears that the CEF content is sometimes drawn on top of our custom window border, like the CEF widget itself is not resized synchronously with the window resize event. This means sometimes the window border is basically invisible -- to the naked eye this looks like flicker/jitter. This is worse in 2171 (i.e. it happens in more of the frames), but it is present in 1547 too.
• When resizing the window larger, the "gaps" are handled differently. 2171 doesn't paint any background fill in the blank areas where CEF hasn't expanded yet, leaving an old copy of the border still visible. Later, once CEF has finished its layout update, it repaints larger and overwrites the old border. To the naked eye, this looks like jitter because the apparent thickness of the border keeps fluctuating. In contrast, 1547 paints a light blue solid fill synchronously with the window resize, so there's never two copies of the border visible at once.

It seems like these are both things we could fix on our end:

• It seems like we should be able to resize CEF's paint/clip region immediately upon resize, even if the HTML/JS layout inside it isn't done updating -- that should ensure CEF never repaints on top of the non-client region.
• We could draw a solid-color window bg ourselves, to mimic the synchronous gap-filling seen in 1547.

However, I'll reiterate that to my eyes, the jitter is only a tiny bit worse than 1547 and seems reasonable enough to ship with.

[peterflynn]

I also checked cefclient 2171 just for kicks. The CEF content is way less responsive to resizing overall (I'm guessing because cefclient is always a debug build?), but it doesn't show either of the problems above. But I'm not sure if it's doing anything specific to repaint the border better, or if that's just something you get for free if you're using the OS-standard Aero border instead of painting your own.

[JeffryBooher]

@peterflynn the installed build seems to paint much faster than my "debug" build so I'm going to lower-the priority on this one for now and remove the milestone.