使用overflow-y:scroll时减少滚动结果; [英] Reducing scroll jank when using overflow-y: scroll;

查看:333
本文介绍了使用overflow-y:scroll时减少滚动结果;的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我有一个2列布局,右栏是一个可滚动的结果列表,其中最多有200项结果(基本上只有一个ul, overflow-y:scroll; set)



当我滚动时,我发现右边的列引起了一些下陷(这在低端硬件上尤其明显)。



在铬时间轴中,当我滚动列时,我可以看到一些主要的更新层树。
有没有什么办法可以找出为什么更新图层树太冗长以及CSS属性对速度的影响最大?
当我点击它时 - 只是给了我它运行多久的信息,没有别的。



我在每个li中都有一些CSS, (例如过滤器,变换,盒子阴影等) -
如果我逐个删除每个SASS文件,它会提高滚动性能(并且一旦删除所有CSS,最终将删除Jank),但显然很难指出哪些CSS属性没有执行此操作。



我不知道是否缺少铬时间轴中的某些内容,可以在这方面提供帮助吗?

我有尝试使用 will-change CSS属性将滚动提升为不同的图层/力量硬件加速 - 但这没有多大区别。



另外当我滚动时,没有javascript事件正在执行。



限制为少于200件不是选项。

我已经设置了一个这样的例子(我知道它是一个较长的项目列表,但这只是演示目的):



修正:



解决方案

我试过



瞬间我们可以看到这个div叫做滚动重画 。然后,您可以在实验图层面板中验证:





< (我在树中右键单击并选择显示内部图层btw)

现在大型的更新图层树成本通常是由大量图层或几个尺寸非常大的图层。在这种情况下,我们确实没有。但是我们有一个滚动层,它没有合成滚动。

合成滚动==快速滚动==通常是默认值。但在这种情况下,我们会回到主线程滚动,这真的很慢,很烂。另一方面,



祝你好运!


I have a 2 column layout, the right hand column is a scrollable result lists with a max of 200 item results (basically just a ul with overflow-y: scroll; set)

What I am finding is that the right hand column is causing some jank (which is especially noticeable on low end hardware) when you scroll.

In the chrome timeline i can see some major "Update Layer tree" while I scroll the column. Is there any way I can figure out why "Update Layer tree" is so lengthy and what CSS properties are affecting speed the most? When I click on it - just gives me info on how long it ran for and nothing else.

I have some CSS in each of the li's that isn't performing very well (eg. filters, transforms, box-shadows etc) - If i remove each SASS file one by one, it improves the scrolling performance (and eventually removes jank once i remove all the CSS), but obviously its hard to pin point which css properties are not performing doing this.

I wonder if im missing something in the chrome timeline that can be helpful in this regard?

I have tried to use the will-change CSS property to promote the scroll to a different layer / force hardware acceleration - but this doesn't make much difference.

Also there is no javascript events executing while I scroll.

Limiting to less than 200 items isn't an option.

I have setup an example of this (I know its a longer list of items, but this is just for demo purposes): https://github.com/jooj123/jank/blob/master/scroll.html

What really interesting is that if i remove the overflow-y: scroll; (in .map-search__results in the example above) the scrolling becomes very smooth and jank disappears - why does this have so much effect?

Here is the chrome timeline (with basically just long "Update Layer tree" sections):

Fix:

Paul's answer about will-change: transform is spot on, in particular this tidbit helped:

"Add will-change: transform;. Once added, the "repaints on scroll" rect is gone."

BUT just be careful as it wont always apply depending on your code base, check the scroll performance issues indicator to make sure "repaints on scroll" is off, for me I had to also disable a -webkit-clip-path property (in my actual code base - not in the demo provided) that was set in one of the child divs, see:

解决方案

I tried out your test page and took a look.

First, with scrolling perf issues I like flipping on a few of the checkboxes in the Rendering pane:

Instantly we can see this div called out as "repaints on scroll". You can then verify that in the experimental Layers panel:

(I right-clicked in the tree and selected "Show internal layers" btw)

Now large "update layer tree" costs are usually caused by LOTS of layers or a few layers that are very large in dimensions. In this case we really have neither. But we do have a scrolling layer that's not getting composited scrolling.

Composited scrolling == fast scrolling == usually the default. But in cases like this we fall back to "main thread scrolling" which is really slow and sucky. On the plus side, crbug.com/381840 is just about to be fixed which should fix this test case automatically. Yay! But we can work around it for now.

The workaround

You did mention you tried will-change and it didn't have an effect, but trying it myself has worked out great. It belongs on the element that has overflow set, in this case its the .map-search__results selector. Add will-change: transform;. Once added, the "repaints on scroll" rect is gone. And measuring with timeline afterwards and it's MUCH better.

Here's a before/after view:

link to viewer

Good luck!

这篇关于使用overflow-y:scroll时减少滚动结果;的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
相关文章
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆