1120859 - Feature Proposal: Make UI more snappy/responsive by tweaking ui. values

Status: RESOLVED INVALID

(Firefox OS Graveyard :: Gaia::System, defect)

Description

[Mozilla_BEC]

User Agent: Mozilla/5.0 (Windows NT 6.3; Win64; x64; rv:25.1) Gecko/20141110 Firefox/31.9 PaleMoon/25.1.0
Build ID: 20141110154537

Steps to reproduce:

Flame v3.0 nightly
Opened Device Preferences in WebIDE

adjusted:
ui.DragThresholdX
ui.DragThresholdY

From 25 to 8

adjusted:
ui.touch_activation.delay_ms

From 100 to 25


Actual results:

UI seems much more snappy and responsive, especially when in the Gallery.

Carefully cropping images became much easier as I had to move less to get the cropper to activate and move.

Quickly swiping between images in Gallery also seems improved as a quick succession of small swipes works reliably, where prior this would be fiddly/inconsistent.


Expected results:

If QA can determine this isn't just placebo or some other change, I think other values should be explored to make the UI feel more accurate/responsive.

Comment 1

[Gregor Wagner [:gwagner]]

Not blocking. Please ask for uplift approval once landed on master.

Comment 2

[Gregor Wagner [:gwagner]]

Gordon, can you take a look here?

Comment 4

[Chris Lord [:cwiiis]]

n?tiffanie to see if there's anyone on UX that could take a quick look at this - I've been running with the changed prefs on my dogfood device for a few weeks now and I can't say I notice much difference, but assuming the values do what they say, we should definitely adjust them (and I'd say the values given in comment #0 are reasonably sensible)

Comment 5

[Chris Lord [:cwiiis]]

Been talking with Tiffanie and she's testing values now. Looking at the code, however, I'm not entirely sure that APZ actually respects these values fully, or that they'll have the exact effect we think.

I've been reading through the code to see what these actually do - touch_activation.delay_ms is just about the delay before an element is marked as CSS 'active', so that we don't highlight stuff while you're scrolling. 100ms sounds reasonable and we should probably leave that.

The drag threshold is, I think, what we expect though, and should likely be smaller, as suggested in comment #0. The touch-screen on the Flame isn't so bad that we'd ever expect 25 pixels worth of jitter on a tap or long-press.

What I'm uncertain of is whether the drag threshold is fully respected by apz. I can see that the value is looked up in TabChild and that a tap won't be generated if you exceed the drag threshold, but does it have any effect on scrolling (as I would expect it should)?

n?botond to answer that question.

Also, I'm just going to take this (though Tiffanie is really doing the hard work here...)

Comment 6

[Chris Lord [:cwiiis]]

(also, are these values display pixels or CSS pixels? I'll look into this more myself too tomorrow)

Comment 7

[Botond Ballo [:botond]]

APZ does not use ui.dragThresholdX / ui.dragThresholdY. Instead, it has its own pref, which is expressed in inches [1].

[1] http://mxr.mozilla.org/mozilla-central/source/modules/libpref/init/all.js?rev=683ba9ea96a3#554

Comment 8

[Botond Ballo [:botond]]

(In reply to Chris Lord [:cwiiis] from comment #6)
> (also, are these values display pixels or CSS pixels? I'll look into this
> more myself too tomorrow)

Given comment 7 this is probably moot, but for the record, ui.dragThresholdX and ui.dragThresholdY are interpreted as being in LayoutDevice pixels.

Comment 9

[Gordon Brander :gordonb]

Does that mean the difference reporters saw when changing these values is actually a placebo effect?

Also, why are these values here (and the corresponding ones for APZC)? I assume they exist to distinguish between touch and drag and that accuracy in one is essentially a trade-off for false positives in the other. Is that true?

Comment 10

[Gordon Brander :gordonb]

^ needsinfo Botond

Comment 11

[Tiffanie Shakespeare [:tif]]

I agree with Chris that the 100ms for the css active state seems reasonable. 

I tested both with the values and with the defaults and it does feel like the drag is more responsive (e.g. cropping in gallery). I didn't really notice much in the way of active state. I think it would be more obvious with a side by side comparison, but given that this is the active state (i.e. visual) and not the actual interaction, I still think the 100ms is fine.

I would be concerned in making changes though if the setting isn't going to be respected everywhere - which seems to be the case per comment 7. We want to make sure the UI feels consistent.

I also want to make sure we aren't impacting anything else before committing the change.

Comment 12

[Botond Ballo [:botond]]

(In reply to Gordon Brander :gordonb from comment #9)
> Does that mean the difference reporters saw when changing these values is
> actually a placebo effect?

Prior to parent-process-apz (bug 950934) landing, scrollable elements in the parent process would still obey the ui.dragThreshold values (since BrowserElementPanning.js uses them), so if they were testing before that landing, they could have been noticing real differences in the parent process UI.

> Also, why are these values here (and the corresponding ones for APZC)? I
> assume they exist to distinguish between touch and drag and that accuracy in
> one is essentially a trade-off for false positives in the other. Is that
> true?

Yep.

Comment 13

[Mozilla_BEC]

> Prior to parent-process-apz (bug 950934) landing, scrollable elements in the
> parent process would still obey the ui.dragThreshold values (since
> BrowserElementPanning.js uses them), so if they were testing before that
> landing, they could have been noticing real differences in the parent
> process UI.
> 
I posted this early January of this year. I had been testing/playing with the values for about a week before I posted this. Had the 950934 bug landed by then already?

Comment 14

[Botond Ballo [:botond]]

(In reply to Brett Edmond Carlock from comment #13)
> > Prior to parent-process-apz (bug 950934) landing, scrollable elements in the
> > parent process would still obey the ui.dragThreshold values (since
> > BrowserElementPanning.js uses them), so if they were testing before that
> > landing, they could have been noticing real differences in the parent
> > process UI.
> > 
> I posted this early January of this year. I had been testing/playing with
> the values for about a week before I posted this. Had the 950934 bug landed
> by then already?

Nope - it landed on Feb 2, and was uplifted to 2.2 on Feb 16.

Comment 15

[Chris Lord [:cwiiis]]

I guess landing of apz and it being enabled everywhere has basically invalidated this bug. Let's open new bugs to tune apz values if and when the time comes.