I'm not able to reproduce this one. Can you confirm that on the same page, moving the window using the mouse has no lag? i.e. only the touch-based dragging is delayed?
Priority: -- → P3
I cannot reproduce the issue using a mouse or the touchpad. It does not have a lag.
status-firefox50: --- → unaffected
Whiteboard: [gfx-noted] → [gfx-noted][nightly only]
Hello Kartikaya, I observe slight lag with fingers/pen/stylus touch too(maybe around 1 second). Using mouse has no lag. Tested on: Surface Pro 4 i5-6300U CPU 2.40GHz
Created attachment 8789053 [details] TinyTake07-09-2016-02-36-11.mp4 This is more noticeable when resizing the window with stylus. https://ranisharma22.tinytake.com/sf/OTU3ODU3XzQwMTM1ODA
Thanks for the video! It looks like maybe we're not coalescing these events as much as we should be, so we're doing lots of wasted intermediate resizes. If that theory is correct it shouldn't be too hard to track down and fix.
status-firefox51: affected → unaffected
status-firefox52: --- → affected
So actually using a stylus resizing the window you are doing in comment 5, I can reproduce this even in 49 release *without* e10s. I don't ever see the lag while moving the window though, on any channel with or without e10s, using stylus or touch. Still, it's probably worth looking into the stylus resizing lagginess and seeing if there is an opportunity for event coalescing that will help. That might fix the window moving lagginess as well.
I spent some time looking into the laggy stylus resizing. As far as I can tell, the windows widget code is getting the same sequence of messages (WM_ENTERSIZEMOVE, WM_SIZING*, WM_EXITSIZEMOVE) regardless of whether mouse or stylus is used. Since I can repro this easily with e10s disabled any overhead/asyncness from the IPC or reflow interruption code is not relevant here. I tried using the Gecko profiler to compare profiles when resizing with mouse vs stylus, and I see that in the stylus case there's a much higher portion of time (~30%) spent in NtUserPeekMessage, but I'm not sure why. I also tried searching MSDN and online for any clues as to whether mouse events get coalesced by Windows more than stylus events but didn't come up with anything. I tried to build the VisualStudio backend so that I might be able to use perf tools in VS to figure out what was going on but after spending over an hour loading the .sln file VS crashed so I don't want to spend any more time on that approach. I'm still unable to reproduce any lag when *moving* the window, only when resizing it with stylus. Not sure what to do here, but I'm fairly confident the fix will be in the windows widget code somewhere.
Component: Panning and Zooming → Widget: Win32
Whiteboard: [gfx-noted][nightly only] → [gfx-noted][nightly only][tpi:+]
Is the version field on this correct? Also, is this really a regression based on comment 7?
There are two issues identified in this bug - (1) is that moving the window with touch is laggy, and (2) is that resizing the window with touch/stylus is laggy. The bug was initially filed about (1) which I cannot reproduce. My comments are about (2) which I can reproduce. (2) doesn't seem to be a regression, but (1) might be. In that case it would be a regression in 52 with touch support enabled.
Version: 51 Branch → 52 Branch
Whiteboard: [gfx-noted][nightly only][tpi:+] → [gfx-noted][tpi:+]
The video in comment 5 is pretty ugly. Is Windows e10s touch support still riding the 52 train? If so, anything we can do to help move this bug along?
(In reply to Ryan VanderMeulen [:RyanVM] from comment #11) > The video in comment 5 is pretty ugly. Is Windows e10s touch support still > riding the 52 train? If so, anything we can do to help move this bug along? We've really never given stylus support priority but maybe it's time to revisit this.
Whiteboard: [gfx-noted][tpi:+] → [gfx-noted][tpi:?]
Priority: P3 → P2
Whiteboard: [gfx-noted][tpi:?] → [gfx-noted][tpi:+]
FWIW I can reproduce the laggy window resizing with the stylus on a Surface Book.
(In reply to Jim Mathies [:jimm] from comment #12) > ... > We've really never given stylus support priority but maybe it's time to > revisit this. Other applications work well, and it seems it's just a question of events getting queued up and processed one by one instead of getting coalesced - Jim, any thought as to who'd be a good person to look at this?
Yes we need to work on this at some point, but currently not a priority.
Priority: P2 → P3
Given comment 15 and a similar comment from Jim offline I'm marking this fix-optional.
status-firefox52: affected → fix-optional
status-firefox53: affected → fix-optional
Summary: [e10s] Nightly moves at a 2-3 second delay when moving window with touch screen → [e10s] Nightly moves at a 2-3 second delay when moving window with stylus on a touch screen
You need to log in before you can comment on or make changes to this bug.