1043822 - Support SW Vsync and combine it with HW Vsync

Status: RESOLVED DUPLICATE of bug 1102631

(Core Graveyard :: Widget: Gonk, defect, P2)

Description

[Boris Chiou [:boris]]

We should implement a SW Vsync for those platforms which don't support hardware composer. This SW Vsync will simulate the Vsync events (60Hz) as the hardware composer does.

Comment 1

[Boris Chiou [:boris]]

Attachment: [WIP] Support SW Vsync Timer (v1)

Use nanosleep to implement SW Vsync Timer

Comment 2

[Boris Chiou [:boris]]

Attachment: [WIP] Support SW Vsync Timer (v2)

Use nanosleep to implement SW Vsync Timer

Comment 3

[Michael Wu [:mwu]]

We have an internal 60fps clock that's used for compositing when there's no hardware source. Why not use that?

Comment 4

[Boris Chiou [:boris]]

(In reply to Michael Wu [:mwu] from comment #3)
> We have an internal 60fps clock that's used for compositing when there's no
> hardware source. Why not use that?

Comment 5

[Boris Chiou [:boris]]

(In reply to Michael Wu [:mwu] from comment #3)
> We have an internal 60fps clock that's used for compositing when there's no
> hardware source. Why not use that?

Compositor usually spends much time for composing. If we don't use a specific thread to do this, it's hard to get a precise 60fps timer.

Comment 6

[Avi Halachmi (:avih)]

(In reply to Boris Chiou [:boris] from comment #5)
> (In reply to Michael Wu [:mwu] from comment #3)
> > We have an internal 60fps clock that's used for compositing when there's no
> > hardware source. Why not use that?
> 
> Compositor usually spends much time for composing. If we don't use a
> specific thread to do this, it's hard to get a precise 60fps timer.

If the only sink of this vsync signal is the compositor, then it doesn't _need_ the external SW signal, since as long as it's busy it can't handle the next composition anyway, regardless of when or where the vsync signal was generated.

On top of that, a thread is not with zero overhead and so are events.

However, an external (to the compositor) SW vsync source could help with few things IMO:

1. Most importantly - unified architecture. The compositor will drop its 60hz code and instead the only vsync generation would reside at one place at the code which could control the rate, HW/SW, etc.

2. If we want to simulate faster refresh frequency for testing (to swamp the compositor for instance), then a single source of vsync would be easier to handle.

3. If there are other consumers for vsync, such as the refresh driver, then an external to the compositor source would be easier to handle.

Regardless of the above,

- The SW vsync signal will need to be error corrected based on actual timestamps. Fixed intervals or fixed rate events would most probably drift (we've seen this at the windows desktop firefox 60hz "emulation" at the refresh driver).

- Most monitors refresh at 59.94 hz and not 60, if you care enough.

Comment 7

[Michael Wu [:mwu]]

(In reply to Avi Halachmi (:avih) from comment #6)
> 1. Most importantly - unified architecture. The compositor will drop its
> 60hz code and instead the only vsync generation would reside at one place at
> the code which could control the rate, HW/SW, etc.
> 

This makes sense if we can get rid of the 60hz clock in both the compositor and refresh driver. Right now, a lot of the code seems to be Gonk specific.

Comment 8

[Boris Chiou [:boris]]

Attachment: [WIP] Support SW Vsync Timer (v2.1)

Use nanosleep to implement SW Vsync Timer

Support StopTimerAsync() and StopTimerSync() in this patch

Comment 9

[Boris Chiou [:boris]]

Attachment: [WIP] Support SW Vsync Timer (v3)

Use nanosleep to implement SW Vsync Timer

Refactor code and revise some APIs.

Try build:
https://tbpl.mozilla.org/?tree=Try&rev=1c6975ba2a42

Comment 10

[Boris Chiou [:boris]]

Attachment: [WIP] Support SW Vsync Timer (v3.1)

Use nanosleep to implement SW Vsync Timer

Fix GetRate().

Try build:
https://tbpl.mozilla.org/?tree=Try&rev=557465dbe211

Comment 11

[Boris Chiou [:boris]]

Attachment: Support SW Vsync Timer (v4)

Use nanosleep to implement SW Vsync Timer.
Fix ICS build errors.

Try build:
https://tbpl.mozilla.org/?tree=Try&rev=333e556fa20f

Comment 12

[Boris Chiou [:boris]]

Attachment: Support SW Vsync Timer (v5)

Use nanosleep to implement SW Vsync Timer. By the way,
I need one mutex for two condition variables, so don't
use any Monitor(one mutex to one condition variable).

Comment 13

[Boris Chiou [:boris]]

Attachment: Support SW Vsync Timer (v6)

Use nanosleep to implement SW Vsync Timer. By the way,
I need one mutex for two condition variables, so don't
use any Monitor(one mutex to one condition variable).

Support SetPriority(), which is implemented by nsThread::SetPriority().

Comment 14

[Boris Chiou [:boris]]

Attachment: Support SW Vsync Timer (v7)

1. Use nanosleep to implement SW Vsync Timer
2. Add soft vsync timer support for PlatformVsyncTimer
3. Add SetPriority() to PlatformVsyncTimer (Default nice value is -2)
4. Add FrameUniformityForceSWVsync pref

Comment 15

[Mason Chang [Inactive] [:mchang]]

From discussing with Avih, we should "tie the new vsync dispatcher to the same pref which defines the rate now - layout.frame_rate, where -1 is the default (vsync or fixed 60hz), 0 is asap, and positive is an explicit refresh rate for firefox" for the software vsync timer. We need both custom rates / as fast as possible as it is used for talos performance tests.