Open Bug 1339043 Opened 7 years ago Updated 10 months ago

Scrolling whiteouts/checkerboarding when panning through lazily populated element (Sencha)

Categories

(Core :: Panning and Zooming, defect, P3)

51 Branch
x86
macOS
defect

Tracking

()

People

(Reporter: johan, Unassigned)

References

(Depends on 1 open bug, )

Details

(Whiteboard: [gfx-noted])

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:51.0) Gecko/20100101 Firefox/51.0
Build ID: 20170125094131

Steps to reproduce:

Visit a page that has a table with "virtual" scrolling, for example:

http://examples.sencha.com/extjs/6.2.0/examples/classic/grid/buffer-grid.html

Two finger "flick" scroll.



Actual results:

Massive whiteouts. Looks really ugly.


Expected results:

No or atleast less whiteouts
OS: Unspecified → Mac OS X
Hardware: Unspecified → x86
Component: Untriaged → Widget: Cocoa
Product: Firefox → Core
Summary: Scrolling whiteouts → Scrolling whiteouts with two fingers
Component: Widget: Cocoa → Panning and Zooming
Status: UNCONFIRMED → NEW
Depends on: displayport-api
Ever confirmed: true
Priority: -- → P3
Whiteboard: [gfx-noted]
Summary: Scrolling whiteouts with two fingers → Scrolling whiteouts/checkerboarding when panning through lazily populated element (Sencha)
Still seeing this in 53.0. Also whiteouts for similar techniques, for example https://clusterize.js.org/. Any progress?
Still present in 56. Do you need any more info?
The solution for this involves fixing the dependency bug (which exposes the displayport to web content) and then updating sencha and other similar frameworks to use it for their virtual scrolling implementation. So this will take a while to fix, but admittedly I should try to push harder for the new web api to be standardised.
Tried today in latest dev edition (58b7), not any better. Is there some kind of workaround one could use? (as a component author)
Trying it on 61.0b2, and it whiteouts much less
Trying it now on 61.0b13, whiteouts are back. Might have been a stroke of luck that it worked better when I tried it out a month ago.

Also noticed it whiteouts on horizontal scroll when trying this:

https://www.bryntum.com/examples/scheduler-latest/examples/bigdataset/

Tried it on 66.0.3 with no better outcome. Try it here for example: https://www.bryntum.com/examples/grid/bigdataset/

Bump, can we get some idea of when can expect FF to deliver performance slightly closer to Chrome? Web apps with big datasets & virtual scrolling isn't exactly an edge case anymore.

(In reply to Kartikaya Gupta (email:kats@mozilla.com) from comment #3)

The solution for this involves fixing the dependency bug (which exposes the
displayport to web content) and then updating sencha and other similar
frameworks to use it for their virtual scrolling implementation. So this
will take a while to fix, but admittedly I should try to push harder for the
new web api to be standardised.

Do we know why the page behaves better in Chrome (as claimed in comment 8) even though Chrome doesn't support a displayport API either? Is it because Chrome doesn't do async scrolling on desktop?

(In reply to Botond Ballo [:botond] from comment #9)

Do we know why the page behaves better in Chrome (as claimed in comment 8) even though Chrome doesn't support a displayport API either? Is it because Chrome doesn't do async scrolling on desktop?

I believe it's just because Chrome can paint faster (at least relative to scroll speed). In previous bugs as well we've seen instances where Firefox checkerboards and Chrome doesn't.

Any news on this issue?

Based on the discussion so far, there are two potential avenues for improvement here:

  1. Spec and implement a displayport API, so that the page can effectively pre-render elements that are not in view yet.
  2. Improve painting performance, so that even if elements are not pre-rendered, the delay between scrolling and rendering them is reduced.

The first is more along the lines of improving the performance of lazy-loading pages like this in all browsers, but it does require cooperation from the page.

The second is more along the lines of making the performance of lazy-loading pages like in Firefox closer to that of Chrome.

Assuming it's more the second thing you're after, have you tried WebRender? It's a major rework of Firefox's graphics pipeline that should bring significant improvements to painting performance on many pages.

Thanks for your feedback. Tried on Win 10 and indeed WebRender greatly reduces the whiteouts, good news. Will await its release on Mac and revisit this topic after that

Severity: normal → S3

Anyone is still following up on it? Any eta about the fix?

Flags: needinfo?(botond)

(In reply to vincent.xue from comment #14)

Anyone is still following up on it? Any eta about the fix?

Are you experiencing an issue like this on a particular site? Could you share the URL?

Proposing a displayport API is still on our radar, though we have not had the bandwidth to schedule work on it thus far. However, the general symptoms described in the bug title could have a number of underlying causes, some of which would be alleviated by a displayport API and others which would not, so it's hard to say more without looking at a specific page.

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