1216090 - Auto adjust the brightness more quickly

Status: RESOLVED WONTFIX

(Firefox OS Graveyard :: Gaia::Settings, defect, P2)

Description

[Cervantes Yu [:cyu] [:cervantes]]

The current algorithm for screen auto brightness doesn't adjust quickly enough when the user goes indoors to outdoors under sunlight.

My current plan is to use a decelerated movement with constant update time when we moving up the brightness. When target is close to current brightness, the adjustment should behave the same as before. When target is far from current, the adjustment should be faster.

Comment 1

[Cervantes Yu [:cyu] [:cervantes]]

Attachment: Attempt 1: decelerated upward adjustment of brightness

I'll dogfood this patch to see how it performs under sunlight.

Comment 2

[Julien Wajsberg [:julienw]]

indoors -> outdoors is quick enough in my opinion, but the other way (outdoors -> indoors) is really slow.

Comment 3

[Cervantes Yu [:cyu] [:cervantes]]

(In reply to Julien Wajsberg [:julienw] (PTO -> 2016) from comment #2)
> indoors -> outdoors is quick enough in my opinion, but the other way
> (outdoors -> indoors) is really slow.

It's by design. Other mobile OSes also perform similarly. Screen being too dark is considered more serious than being too bright. Having an asymmetric adjustment speed is also a contributor to the stability of auto brightness. If we make outdoors->indoors equally quick, we may find that the screen flickers indoors, say, the user walks under ceiling lights.

Comment 4

[Julien Wajsberg [:julienw]]

I'll need to find a correct STR but I remember some times where it was really painful to have the screen too bright in a really dark environment.

Maybe it's possible to see that if the target stays low for several seconds we can go faster ?

This is likely what you proposed in comment 0 for moving up, but I favor the same behavior for moving down :)

BTW when you write "decelerated" did you mean "accelerated" ? It goes faster and faster ?

Comment 5

[Cervantes Yu [:cyu] [:cervantes]]

(In reply to Julien Wajsberg [:julienw] (PTO -> 2016) from comment #4)
> I'll need to find a correct STR but I remember some times where it was
> really painful to have the screen too bright in a really dark environment.
> 
Was it adjusting, or the brightness just stayed the same for more than 30 sec? You should be able to see the screen adjust brightness gradually if you were in a really dark environment, but there is a 5 sec cooldown time before the adjustment starts. If the brightness didn't eventually get updated, there might be a bug that auto brightness is not functioning.

> Maybe it's possible to see that if the target stays low for several seconds
> we can go faster ?
> 
If the target is really distant from the current value, it will soon be reflected in ScreenAutoBrightnessValues.getAverage() because the array has a limited capacity of 5 and the brightness sensor generates values in less than 200 ms. It only takes < 1 sec that we decide to go down fast.

> This is likely what you proposed in comment 0 for moving up, but I favor the
> same behavior for moving down :)
> 
We already have decelerated movement for moving down. But the movement is slower than moving up.

> BTW when you write "decelerated" did you mean "accelerated" ? It goes faster
> and faster ?

No, I do mean decelerated. Deceleration is key to automatic control system. It goes fast initially when target brightness is far from current value and slows down when it gets closer and closer. Accelerated movement will lead the system to divergence and oscillation.

Comment 6

[:Atoll]

Is there a log bit to flip on for the auto-brightness system, that logs "measured" brightness on a regular basis and whether it chose to adjust or not?

Comment 7

[Cervantes Yu [:cyu] [:cervantes]]

No, debug logs are stripped before the patch is submitted for review and landing.