685702 - investigate responsiveness gap between mouse & drag events

Status: RESOLVED INCOMPLETE

(Core :: DOM: Copy & Paste and Drag & Drop, defect)

Description

[Frank Yan (:fryn)]

The primary reason for using mouse events in the current implementation of tab animations is their superior responsiveness. However, it has become apparent that drag events have enough useful properties that make rewriting tab animations with them a worthwhile endeavor. If the responsiveness gap between the two sets of events can be closed, we can have the best of both worlds.

I've created two simple testcases: one using plain mouse events and the other using drag events. I will upload these shortly. If you could look into why the gap exists and how it could be mitigated or even eliminated, it will be much appreciated.

If this bug is in the wrong component, feel free to move it.

Comment 1

[Frank Yan (:fryn)]

Attachment: XUL Testcase with Mouse Events

Here's the testcase with mouse events. It's superior in responsiveness and in the ability to detect drags over a window's titlebar and anywhere outside of the document.

Comment 2

[Frank Yan (:fryn)]

Attachment: XUL Testcase with Drag Events

Here's the testcase that uses drag events. Notice that it is slower to respond and seems to stutter more with a lower frame rate. Also, when the XUL document is being rendered as a top-level window, no dragover events are fired while over the titlebar.

I have to use `dragover` events instead of `drag` events, because screen coordinates are not provided for `drag` events (see bug 505521), which is very problematic for tab animations.

Comment 3

[Neil Deakin]

Both these testcases show smooth performance to me. I tested on a debug build on Ubuntu.

Comment 4

[Lozzy]

(In reply to Neil Deakin from comment #3)
> Both these testcases show smooth performance to me. I tested on a debug
> build on Ubuntu.

Same here (Win7 x64).

I wondered if perhaps I wasn't using the test cases correctly or if it was just me. This was particularly due to fryn mentioning "It's superior in [...] the ability to detect drags over a window's titlebar". I can't seem to do any interactions like that, only drag the tabs horizontally.

Comment 5

[Frank Yan (:fryn)]

(In reply to Lozzy from comment #4)
> I wondered if perhaps I wasn't using the test cases correctly or if it was
> just me. This was particularly due to fryn mentioning "It's superior in
> [...] the ability to detect drags over a window's titlebar". I can't seem to
> do any interactions like that, only drag the tabs horizontally.

Because I can't use a `drag` event handler, I'm using a `dragover` event handler, which means that I can't detect when a drag moves over the titlebar of the document's window on OS X and Ubuntu. This is problematic because there should be a vertical threshold for tab detaching, and I can't implement that without the ability to get screen coordinates for `drag` events. See bug 505521.

Neil, any ideas on how we could get screen coordinates for `drag` events?

Comment 6

[Neil Deakin]

It requires an answer to https://bugzilla.mozilla.org/show_bug.cgi?id=505521#c6

Comment 7

[Frank Yan (:fryn)]

(In reply to Neil Deakin from comment #6)
> It requires an answer to
> https://bugzilla.mozilla.org/show_bug.cgi?id=505521#c6

My answer is that the coordinates should be given relative to the window containing the element that is the target of the drag event. More precisely, this window is the window whose top-left corner is used for calculating element.boxObject.screenX/Y, where element is the target of the drag event.

Comment 8

[Frank Yan (:fryn)]

(In reply to Frank Yan [:fryn] from comment #7)

Correction: By window, I meant screen.

Comment 9

[Dão Gottwald [:dao]]

(In reply to Neil Deakin from comment #3)
> Both these testcases show smooth performance to me. I tested on a debug
> build on Ubuntu.

Ditto. Tested with my old netbook on Win XP.

Comment 10

[Marco Bonardo [:mak]]

the mouse events one is a bit less stuttering on my system (i7, win7 x64), but it's pretty much subtle, likely most users would not notice, but I wonder if it would be more visible on slower systems.

Comment 11

[Alex Limi (:limi) — Firefox UX Team]

Drag events are much worse for me on OS X, at least. 

Testing Frank's new tab dragging patch on a latest-gen MacBook Air (Intel Core i7, Intel HD 3000 graphics), and it's noticably slower than the previous implementation that used mouse events.

Comment 13

[Frank Yan (:fryn)]

Attachment: Full perf report of tab switch jank created by :jlebar

Justin Lebar [:jlebar] wrote his original filing of bug 801509:

> Mozilla/5.0 (X11; Linux x86_64; rv:19.0) Gecko/19.0 Firefox/19.0
> 
> Like bug 786397, but that seems to have fixed itself.
> 
> STR: Drag a tab around the tab bar.  It janks.
> 
> Profiling coming in a moment.

> perf shows that we're spending a lot of time in malloc and free, which is
> interesting.  It seems to be coming from layout?

See bug 801509 comment #1 for a partial report.

> It's not all from layout; 50% of malloc calls are coming from g_malloc,
> which I can't see past in the stacktrace.
> 
> Here are the top few functions and abbreviated stack traces from perf.  I'll
> attach the full perf report in a moment, but it's not fun to read.  Note
> that all the arena_ functions are part of malloc or free.

See bug 801509 comment #2 for a partial report.

Comment 14

[Frank Yan (:fryn)]

Thanks for profiling this, Justin!