Closed Bug 775465 Opened 12 years ago Closed 7 years ago

Investigate porting "smooth scrolling" to async pan/zoom machinery

Categories

(Core :: Graphics: Layers, defect)

defect
Not set
normal

Tracking

()

RESOLVED WORKSFORME
blocking-basecamp -

People

(Reporter: cjones, Unassigned)

References

Details

The prerequisite for this is omtc, otherwise we don't have much room to improve UX.

The way I think this could work is
 - when we request smooth (async) scrolling for nsGfxScrollFrameInner, we force its content to layerize.  Shades of CSS transform/animations etc.
 - we enlarge the rendered area of the scroll frame, a la displayport
 - we create an AsyncPanZoomController for that layer / ID
 - events targeting the frame are also passed off to the apzc
 - nsGfxScrollFrameInner (or something near it) implements its own "GeckoContentController" that simply updates the scroll offset of the scroll as requested

This would let us maintain 60fps user-visible performance while possibly avoiding some intermediate reflows and repaints.

The UX question that we always come back to here is what to do when drawing an animation frame would require drawing unrendered content.  One option is to draw fallback content like the background color or something else ("checkerboard" in "mobile" jargon).  Another option is to just not use the currently sampled transform, i.e. stay within rendered content.

I think this would actually be relatively easy to implement.  It would be an interesting experiment once we enable omtc for some desktop platforms.
(In reply to Chris Jones [:cjones] [:warhammer] from comment #0)
> This would let us maintain 60fps user-visible performance while possibly
> avoiding some intermediate reflows and repaints.
> 

And, obviously, hiding the latency of long-running events like GC or content JS.
We took a look at the blockers for bug 745136 during B2G triage today.  The consensus was that this wasn't a blocker.  Please re-nom if you'd like that re-considered.  Note that no one's opposed to this being fixed, we just don't think we'd hold the release for it :)
blocking-basecamp: --- → -
This only applies to "desktop", so not even on the basecamp radar.
This is basically done now.
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.