Fixes removeClipSubviews check for offscreen rendering of ListViews #15669

MattFoley · 2017-08-27T00:21:37Z

This issue has been open for a really long time, but I'm pretty sure this is the line that needed to change:
#1831

What was happening here is that CGRectIsEmpty returns true when either height or width is zero. With the current logic, one of those would always be zero when the parent was rendered off screen. This ensures that there the intersection be of CGSizeZero for the view to actually be clipped.

That being said, there seems to be something more complex going on here that I'm not understanding? I would think that you'd simply want to check if the child view's frame is within the bounds of the parent at all. If it was, then don't clip it. If I'm in the wrong, could someone explain this a bit more? If so, I'll fix this issue.

Test Plan

Using this repository, this one line change fixes the issue and still clips cells as they are scrolled off screen.

This issue has been open for a really long time, but I'm pretty sure this is the line that needed to change: facebook#1831 What was happening here is that `CGRectIsEmpty` returns true when either height or width is zero. With the current logic, one of those would always be zero when the parent was rendered off screen. This ensures that there the intersection have a CGSizeZero for the view to actually be clipped. Using this [repository](https://github.com/jcharlet/react_native_listview_bug), this one line change fixes the issue and still clips cells as they are scrolled off screen. That being said, there seems to be something more complex going on here that I'm not understanding? I would think that you'd simply want to check if the child view's frame is within the bounds of the parent at all. If it was, then don't clip it. If I'm in the wrong, could someone explain this a bit more? If so, I'll fix this issue.

pull-bot · 2017-08-27T00:29:39Z

Attention: @shergin

Generated by 🚫 dangerJS

shergin · 2017-08-27T00:33:16Z

@MattFoley Do you have a test case for this?

MattFoley · 2017-08-27T00:54:22Z

@shergin I don't and I'm honestly not sure where to start with that. It looks like there aren't any tests around clipping yet. Do you think you could give me a hand? What would be expected?

shergin · 2017-08-27T01:07:03Z

Starting just from a demo app which did not work properly before would be a good start.

MattFoley · 2017-08-27T22:54:59Z

@shergin That I do have. If you view this repository with no changes, you'll notice that after launch/refresh and tap to the second tab, the cells there do not display on iOS until you scroll them. Once you add my fix, that no longer happens, and it still removes the subviews properly when scrolled off screen.

The current workaround that I've been using (mentioned in this issue) is to render the ListView with removeClippedSubviews set to true, and then changing this to false after it moves into view. Apparently people have found similar workarounds for FlatList and other ScrollView based components, there's a ton of information in that thread. (Hard for me to follow all of it actually)

Does that work?

shergin · 2017-08-29T05:24:45Z

Here the thing, both ListView and removeClipSubviews are deprecated, and this mean that it is unlikely that someone from core team at Facebook will investigate this pretty magical problem. 😞
But if someone with good karma assures me that this is a right approach, I will merge this.
I am really sorry, but at this moment we are more affraid to break something stable/old than want to make other old and deprecated thing better.
Anyone? 😄
cc @janicduplessis

MattFoley · 2017-08-29T23:03:56Z

@shergin Are you sure removeClippedSubviews is deprecated? I don't see this mentioned anywhere in the documentation or code.

Also, this isn't just a problem with ListView, that issue I linked has reports of people having the same problem with FlatList. I would guess this issue effects ScrollView, and other Views in some circumstances. (Although, I could totally be wrong)

shergin · 2017-08-30T21:00:05Z

@MattFoley

Are you sure removeClippedSubviews is deprecated? I don't see this mentioned anywhere in the documentation or code.

Technically, it is not deprecated. Yet. But we are thinking about this. We see a lot of issues and negative side effects caused by this feature, and at the same time the positive possible benefits from this is very limited.
This feature will not be removed until it provides some significant benefits though.
We don't use it for <FlatList>, AFAIK. So, it should not be related. (Right?)

MattFoley · 2017-09-01T15:33:40Z

@shergin FlatList is a subclass of VirtualizedList, which is a subclass of ScrollView, which is in turn implemented by RCTScrollView on the native ObjC side, which is then a subclass of RCTView. I'm running a slightly older version of RN, but I think that means that even FlatList would be impacted by issues with the removeClippedSubviews calculation.

Do you guys have a back up in place for removing removeClippedSubviews?

Any Table/Cell component needs the ability to pop offscreen views, and reuse them. It's a major performance bottleneck if not. RecyclerView and UITabletView both do this almost automatically for the developer, so it would be a shame if this was removed without a replacement.

chirag04 · 2017-09-01T18:24:18Z

related: #13316

kozillla · 2017-09-08T05:18:00Z

I am experiencing the same issue with FlatList.
As https://facebook.github.io/react-native/docs/flatlist.html states "Note: may have bugs (missing content) in some circumstances - use at your own risk.This may improve scroll performance for large lists.".

Is it in any roadmap to when we can expect fix for it ?

nihgwu · 2017-09-08T05:34:23Z

that's really an aged issue, #8607 #1831

shergin · 2017-09-09T04:52:16Z

@MattFoley I am affraid removingClippingSubviews feature cannot help with recycling (it cannot reduce memory footprint), it works differently.
Yes, as I mentioned earlier, this feature will not be removed until we have "back up plan".
AFAIK, enabling removingClippingSubviews for FlatList does not makes much sense since FlatList does recycle views (so there is no need to remove them from view hierarchy).

MattFoley · 2017-09-11T01:06:20Z

@shergin The issue I linked above still has people running into problems. I get a couple emails a week with replys to that issue. If my PR isn’t sufficient, can a fix for this be prioritised? It seems like a real problem that many people are having with both ListView and FlatList.

lprhodes · 2017-09-11T01:14:13Z

It's a significant issue for every one of our apps. I'm unsure how the issue has gone under the radar for so long.

Using removeClipSubviews certainly has an impact on app performance, especially with older devices so I hope it won't be the case that it's removed.

narychen · 2017-09-11T08:10:03Z

@MattFoley It indeed fixes my issue. I'm using the old version 0.27.2 of react-native and cannot update since I changed too much native code. But I have to turn the removeClipSubviews on because if turn it off the app will soon crash due to the memory issue as my app has too many GIF images.
But after I merged your code and get removeClipSubviews still be true. The ListView rows never will be blank again.
You are amazing. Thank you really very much.

kelset · 2017-09-11T09:23:55Z

I understand that removingClippingSubviews will be removed/deprecated soon - but this fix has quite a small footprint; it's more like an hotfix to me, I'd love to see it merged & cherry-picked in 0.49 :3

kozillla · 2017-09-11T12:27:08Z

@MattFoley Thanks a lot for fixing this up. Im using the latest react-native ver 0.48.1 with your fix. It works fine in majority of cases, how ever Im still running into scenario whenFlatList becomes blank.

sahrens · 2017-09-11T19:26:23Z

Sounds like we should merge this.

Note FlatList doesn't set removeClippedSubviews by default, but developers may set it manually. More importantly, other libraries like navigation my use removeClippedSubviews which causes the proble.

MattFoley · 2017-09-11T21:55:17Z

@sahrens I had assumed it was defaulted to true everywhere. I just dug around and found that actually only ListView and WindowedListView set it to true by default. Perhaps FlatList has a different issue (or maybe they're just setting it to true for the performance?).

I think I've started understanding the more complex logic in this function. I think it's using the extra intersection logic to compensate for if a parent subview is only partially on screen, but the subview it's checking is still off screen. That must be why it's not just checking if it's within the bounds of it's parent. I'm not sure if that's a worthwhile optimization or not.

What do you think? Would it be better to simply check if a view is within the bounds of it's parent and clip it if it's not?

facebook-github-bot · 2017-09-12T16:58:26Z