Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[ASDisplayNode] cancelAsyncDisplay must clear dirty contents of layer #113

Open
garrettmoon opened this issue May 1, 2017 · 5 comments
Open

Comments

@garrettmoon
Copy link
Member

From @molon on November 26, 2015 13:20

Hi,
There's a ASTextNode in a ASLazyLoadCellNode.
I try to set attributedString to it at the end of table view.
Then I insert new rows.

This is just the happen scene upon.

debug below:
some test I added:
qq20151126-0 2x
break at the function
qq20151126-2 2x
the output, we can see it breaks before the last isCancelledBlock
qq20151126-1 2x
We can see that the willMoveToWindow:(window is nil) is called because of inserting rows.
it cause cancelAsyncDisplay to be called. This led to dirty contents of layer.
qq20151126-3 2x

Then the last isCancelledBlock will return YES. The last draw attributedString will be ignored. So it layer.content is stale(dirty) now.

__enterHierarchy will be called when willMoveToWindow(window is not nil).
setNeedsDisplay is called in __enterHierarchy when layer.content == nil.
But the layer.content==nil can only ensure the layer will be redraw when nil, not stale(dirty).
And It's really dirty sometimes.

eg:
updateVisibleNodeIndexPaths will lead to recursivelyClearContents with some indexPaths. it's ok.
But [_layoutController indexPathsForScrolling:_scrollDirection viewportSize:viewportSize rangeType:rangeType] will return indexPaths which not visible sometimes, thus these rows will be remove from window by configureContentView:forCellNode: but havn't clear content.
So the rows will not be redisplay. I think it's a BUG.

In summary, the cancelAsyncDisplay only cancel the next drawing of layer, but! but! not clear the dirty contents of layer. So it will be not redraw because it's contents not nil ,when the layer display again,

I think views is not necessary to call cancelAsyncDisplay after removing from a window unless we can throw the dirty contents away.
It will cause some unforeseen circumstances.

:)

Copied from original issue: facebookarchive/AsyncDisplayKit#889

@garrettmoon
Copy link
Member Author

From @appleguy on November 28, 2015 2:51

@molon thank you for the detailed description! I understand most of what you've discovered, but in my first read-through, don't yet understand as much as you do. I may be able to fully understand when I can look into the code alongside reading your description, but since I'm on a plane that is about to push back from the gate, I'll start with a question for you!

Question: are you saying that in this situation, the display is cancelled /but no replacement display is scheduled, and it should be scheduled/?

Do you believe that it should be cancelled and then re-displayed, or do you believe that it is always safe to avoid cancelling in this situation entirely and no re-display is needed?

I'm really glad you dug into the implementation here, as these days I am one of the only folks looking at this particular code path :).

@garrettmoon
Copy link
Member Author

From @molon on November 28, 2015 5:1

@appleguy thanks for answer.

Question 1:
Yes. if it's layer.content is nil, it would be re-display. But sometimes it's layer.content is stale not nil.
a stale layer.content must follows scheduled display.

Question 2:
I believe that (avoid cancelling when node __exitHierarchy) is good choice.
layer.content should be always fresh or nil when no scheduled display.

I'm glad to learn so much from the library. :)

@garrettmoon
Copy link
Member Author

@appleguy do you think this is still an issue?

@garrettmoon
Copy link
Member Author

From @appleguy on November 28, 2016 1:40

Pulling this into 2.0.1 so it can be evaluated in more detail and then triaged to the right milestone if it can't be fixed immediately.

@garrettmoon
Copy link
Member Author

From @appleguy on November 28, 2016 1:40

@Adlai-Holler has looked at the async display system a good bit (transactions), so he could coordinate with @nguyenhuy to decide which one of them has cycles post-2.0 to investigate.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants