Open Bug 1735391 Opened 3 years ago Updated 1 year ago

[meta] Reduce compositing latency by waiting for vsync in fewer cases

Categories

(Core :: Graphics: WebRender, task)

task

Tracking

()

People

(Reporter: mstange, Unassigned)

References

(Blocks 4 open bugs)

Details

(Keywords: meta)

Profile: https://share.firefox.dev/3mKekgx

Firefox currently has an increased latency of putting changes on the screen, compared to other browsers. This affects the responsiveness of keyboard typing, scrolling, and mouse move feedback.

The latency is incurred when the compositor waits for a vsync notification to kick off the composite; we currently only ever composite from a vsync notification, never between vsyncs.

We should consider switching to a model where we composite once per vsync, but at any point during the vsync interval, with the intention that we composite right after the main thread paint is finished. In the keyboard input case, this should allow us to run the keyboard event handler, the main thread paint, and the composite sequentially without gaps, and means that we should usually composite in the same vsync interval as we get the event.

Compositing only from vsync has other shortcomings too, for example it causes stutter for touchpad scrolling if the native scroll events race with the vsync notification (bug 1715317, bug 1641070).

Blocks: 1715317
Blocks: 1641070

The meta keyword is there, the bug doesn't depend on other bugs and there is no activity for 12 months.
:gw, maybe it's time to close this bug?

Flags: needinfo?(gwatson)

Redirecting to mstange - this probably shouldn't be in the WR component either.

Flags: needinfo?(gwatson) → needinfo?(mstange.moz)

Not sure which component it should be in, but it definitely is still something that's worth fixing.

Flags: needinfo?(mstange.moz)
You need to log in before you can comment on or make changes to this bug.