Closed Bug 730914 Opened 8 years ago Closed 7 years ago

Paint directly from ScrollTo

Categories

(Core :: Graphics, defect)

x86
macOS
defect
Not set

Tracking

()

RESOLVED DUPLICATE of bug 745315

People

(Reporter: jrmuizel, Unassigned)

References

Details

Currently we have some indirection between our call to ScrollTo and actually beginning painting. There two reasons, we wait for the refresh driver to coalesce the invalidation and call nsWindow::Invalidate(). Invalidate(), also queues up an event instead of painting immediately.
(In reply to Jeff Muizelaar [:jrmuizel] from comment #0)
> Currently we have some indirection between our call to ScrollTo and actually
> beginning painting. There two reasons, we wait for the refresh driver to
> coalesce the invalidation and call nsWindow::Invalidate(). Invalidate(),
> also queues up an event instead of painting immediately.

On maple the time between the end of ScrollTo and the beginning of OnDraw seems to be between 0.24-12ms
Display list based invalidation will fix half of this, I've moved painting to happen directly from the refresh driver flush instead of waiting for the widget draw event.
(In reply to Matt Woodrow (:mattwoodrow) from comment #2)
> Display list based invalidation will fix half of this, I've moved painting
> to happen directly from the refresh driver flush instead of waiting for the
> widget draw event.

Yummy.
If DLBI takes care of the latency between refresh driver flushing and actually painting, then the other half of this bug is covered by bug 745315. Duping.
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 745315
You need to log in before you can comment on or make changes to this bug.