[e10s] Nightly moves at a 2-3 second delay when moving window with stylus on a touch screen

NEW
Unassigned

Status

()

P3
normal
2 years ago
2 years ago

People

(Reporter: Grover-QA, Unassigned)

Tracking

({regression})

52 Branch
x86
Windows 10
regression
Points:
---

Firefox Tracking Flags

(e10s+, firefox49 unaffected, firefox50 unaffected, firefox51 unaffected, firefox52 fix-optional, firefox53 fix-optional)

Details

(Whiteboard: [gfx-noted][tpi:+])

Attachments

(1 attachment)

(Reporter)

Description

2 years ago
Mozilla/5.0 (Windows NT 10.0; rv 51.0) Gecko/20100101 Firefox/51.0

[Pre-Requisites] 
javascript.options.asyncstack; false
browser.tabs.remote.force-enable; true
browser.tabs.remote.autostart.2; true 
about:support Multiprocess Windows 1/1 (Enabled by user)
layers.async-pan-zoom.enabled; true 
about:support Asynchronous Pan/Zoom wheel input enabled; touch input enabled

[Steps to Reproduce]
1. Navigate to a URL (eg: http://www.whatisblik.com/ )
2. Using your finger hold and press on the Title Bar to drag the windows

[Expected Results]
The window does not move with a noticeable delay.

[Actual Results]
The window moves with a noticeable delay. (Up to 3 seconds behind the user finger input)

[Note]
This only happens when e10s is enabled. When e10s is disabled, the window does not move with a noticeable delay.
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?
Flags: needinfo?(gwimberly)
Priority: -- → P3
Whiteboard: [gfx-noted]
(Reporter)

Comment 2

2 years ago
I cannot reproduce the issue using a mouse or the touchpad. It does not have a lag.
Flags: needinfo?(gwimberly)
Ok, thanks.
Blocks: 1244402
status-firefox50: --- → unaffected
Whiteboard: [gfx-noted] → [gfx-noted][nightly only]

Comment 4

2 years ago
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

Updated

2 years ago
tracking-e10s: ? → +

Updated

2 years ago
Keywords: regression
status-firefox49: --- → unaffected

Comment 5

2 years ago
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

Updated

2 years ago
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?
Flags: needinfo?(jmathies)
(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.
Flags: needinfo?(jmathies)
Whiteboard: [gfx-noted][tpi:+] → [gfx-noted][tpi:?]

Updated

2 years ago
Priority: P3 → P2
Whiteboard: [gfx-noted][tpi:?] → [gfx-noted][tpi:+]
status-firefox53: --- → affected
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?
Flags: needinfo?(jmathies)
Yes we need to work on this at some point, but currently not a priority.
Flags: needinfo?(jmathies)
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.