Scrolling whiteouts/checkerboarding when panning through lazily populated element (Sencha)
Categories
(Core :: Panning and Zooming, defect, P3)
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
Updated•7 years ago
|
Updated•7 years ago
|
Updated•7 years ago
|
Still seeing this in 53.0. Also whiteouts for similar techniques, for example https://clusterize.js.org/. Any progress?
Comment 3•7 years ago
|
||
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 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.
Comment 9•5 years ago
•
|
||
(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?
Comment 10•5 years ago
|
||
(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.
Reporter | ||
Comment 11•5 years ago
|
||
Any news on this issue?
Comment 12•5 years ago
|
||
Based on the discussion so far, there are two potential avenues for improvement here:
- Spec and implement a displayport API, so that the page can effectively pre-render elements that are not in view yet.
- 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.
Reporter | ||
Comment 13•5 years ago
|
||
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
Updated•2 years ago
|
Comment 14•10 months ago
|
||
Anyone is still following up on it? Any eta about the fix?
Comment 15•10 months ago
•
|
||
(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.
Description
•