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

[core-ai-bot]

Issue by dalcala
Tuesday Aug 20, 2013 at 17:46 GMT
Originally opened as adobe/brackets#4841

---

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 adobe/brackets#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.

[core-ai-bot]

Comment by gruehle
Monday Aug 26, 2013 at 18:39 GMT

---

Reviewed. Medium priority to@JeffryBooher

[core-ai-bot]

Comment by rajeshsegu
Friday Aug 30, 2013 at 17:52 GMT

---

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.

[core-ai-bot]

Comment by redmunds
Saturday Nov 16, 2013 at 01:46 GMT

---

@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?

[core-ai-bot]

Comment by peterflynn
Tuesday Mar 18, 2014 at 04:31 GMT

---

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

[core-ai-bot]

Comment by JeffryBooher
Tuesday May 27, 2014 at 19:24 GMT

---

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

[core-ai-bot]

Comment by JeffryBooher
Tuesday Nov 18, 2014 at 22:17 GMT

---

WOW. This got incredibly worse with CEF 2171

[core-ai-bot]

Comment by JeffryBooher
Friday Nov 21, 2014 at 23:15 GMT

---

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

[core-ai-bot]

Comment by peterflynn
Wednesday Dec 03, 2014 at 08:18 GMT

---

@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.

[core-ai-bot]

Comment by RaymondLim
Wednesday Dec 03, 2014 at 08:28 GMT

---

@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.

[core-ai-bot]

Comment by peterflynn
Thursday Dec 04, 2014 at 01:57 GMT

---

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.

[core-ai-bot]

Comment by peterflynn
Thursday Dec 04, 2014 at 02:10 GMT

---

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.

[core-ai-bot]

Comment by JeffryBooher
Friday Dec 05, 2014 at 00:26 GMT

---

@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.