Closed Bug 1231420 Opened 9 years ago Closed 8 years ago

APZ gets multiple updates that lag behind the currently displayed area

Categories

(Core :: Panning and Zooming, defect)

Product:
Core
Component:
Panning and Zooming
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED DUPLICATE of bug 1236035

People

(Reporter: jrmuizel, Unassigned)

References

Details

When scrolling quickly the minimaps shows the the currently displayed area can get far away from the painted area and we'll get new painted areas that are still far behind the current area even after the scrolling has stopped.
I think this is a symptom of a larger problem which I'm using bug 1209970 for. In general the repaint requests that get sent from APZ to the main thread are kind of ad-hoc and I would like to clean it up so that they are more deterministic with respect to vsync.
Depends on: 1209970
(In reply to Kartikaya Gupta (email:kats@mozilla.com) from comment #1)
> I think this is a symptom of a larger problem which I'm using bug 1209970
> for. In general the repaint requests that get sent from APZ to the main
> thread are kind of ad-hoc and I would like to clean it up so that they are
> more deterministic with respect to vsync.

Will we cancel paints that we've asked for that are of no use to us anymore?
The progressive painting code is supposed to abort the useless paints. Once we send the repaint request from APZ we have no way of canceling it. However, we do throttle paints so that we don't have more than one inflight at a time, so we shouldn't be sending really stale repaints either.
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.