IncrementalPreview #4953

Closed
wants to merge 1 commit into
from

Conversation

Projects
None yet
9 participants
@sahrens
Contributor

sahrens commented Dec 23, 2015

Preview of new experimental Incremental concept for feedback. I have D2506522 internally that is the source of truth and necessary InteractionManager changes that are in the process of landing.

The problem addressed here is expensive components that can tie up the JS thread during render, making the app unresponsive to taps, the canonical example being scroll loading of expensive rows. The approach is to slice up the rendering into separate chunks of work separated by setTimeout calls.

Everything wrapped in <Incremental> is rendered sequentially via InteractionManager.
The onDone callback is called when all descendent incremental components have
finished rendering, used by <IncrementalPresenter> to make the story visible all at once
instead of the parts popping in randomly.

This includes an example that demonstrates streaming rendering and the use of
<IncrementalPresenter>. Pressing down pauses rendering and you can see the
TouchableOpacity animation runs smoothly. Video:

https://youtu.be/4UNf4-8orQ4

Plan is to use this in WindowedListView and get that out as an Experimental component in open source soon as well.

Note that the new setDeadline method must be called on InteractionManager, otherwise everything will just get batches up in setImmediate. We should consider changing that default.

Ideally this will be baked into React Core at some point, but according to @jwalke that's
going to require a major refactoring and take a long time, so going with this for now.

IncrementalPreview
Preview of new experimental Incremental concept for feedback.  I have D2506522 internally that is the source of truth.

Video:
https://youtu.be/4UNf4-8orQ4
@brentvatne

This comment has been minimized.

Show comment
Hide comment
@brentvatne

brentvatne Dec 23, 2015

Collaborator

🚀 🎸

Collaborator

brentvatne commented Dec 23, 2015

🚀 🎸

@dsibiski

This comment has been minimized.

Show comment
Hide comment
@dsibiski

dsibiski Dec 24, 2015

Contributor

Oooooh! 😍

Contributor

dsibiski commented Dec 24, 2015

Oooooh! 😍

@brentvatne

This comment has been minimized.

Show comment
Hide comment
@brentvatne

brentvatne Dec 24, 2015

Collaborator

My thoughts (as @sahrens and I discussed elsewhere) -- it would be neat to find a way to integrate requestIdleCallback (perhaps optionally) in order to further de-prioritize incremental rendering, so incremental chunks only start when there is some 'idle' time. This could be optional.

Collaborator

brentvatne commented Dec 24, 2015

My thoughts (as @sahrens and I discussed elsewhere) -- it would be neat to find a way to integrate requestIdleCallback (perhaps optionally) in order to further de-prioritize incremental rendering, so incremental chunks only start when there is some 'idle' time. This could be optional.

@chandu0101

This comment has been minimized.

Show comment
Hide comment
@chandu0101

chandu0101 Dec 24, 2015

Contributor

does this solve js navigator transitions issue ..?

Contributor

chandu0101 commented Dec 24, 2015

does this solve js navigator transitions issue ..?

@brentvatne

This comment has been minimized.

Show comment
Hide comment
@brentvatne

brentvatne Dec 24, 2015

Collaborator

@chandu0101 - it could help if your views in the new scene are all inside of incremental presenters. there is other work being done to specifically address that right now though -- offloading animations to main thread.

Collaborator

brentvatne commented Dec 24, 2015

@chandu0101 - it could help if your views in the new scene are all inside of incremental presenters. there is other work being done to specifically address that right now though -- offloading animations to main thread.

@chandu0101

This comment has been minimized.

Show comment
Hide comment
@chandu0101

chandu0101 Dec 24, 2015

Contributor

it could help if your views in the new scene are all inside of incremental presenters. there is other work being done to specifically address that right now though -- offloading animations to main thread.

cool ok , thanks for info :)

Contributor

chandu0101 commented Dec 24, 2015

it could help if your views in the new scene are all inside of incremental presenters. there is other work being done to specifically address that right now though -- offloading animations to main thread.

cool ok , thanks for info :)

@ssssssssssss

This comment has been minimized.

Show comment
Hide comment
@ssssssssssss

ssssssssssss Dec 25, 2015

🚀 🎸 Does the experimental WindowedListView solves the memory hungry issue for a long list?

🚀 🎸 Does the experimental WindowedListView solves the memory hungry issue for a long list?

@sahrens

This comment has been minimized.

Show comment
Hide comment
@sahrens

sahrens Dec 25, 2015

Contributor

Yes, WindowedListView is focused on the memory usage of infinite lists, but there are tradeoffs, especially because it is designed for variable height rows.

On Dec 24, 2015, at 5:25 PM, fxwan notifications@github.com wrote:

Does the experimental WindowedListView solves the memory hungry issue for a long list?


Reply to this email directly or view it on GitHub.

Contributor

sahrens commented Dec 25, 2015

Yes, WindowedListView is focused on the memory usage of infinite lists, but there are tradeoffs, especially because it is designed for variable height rows.

On Dec 24, 2015, at 5:25 PM, fxwan notifications@github.com wrote:

Does the experimental WindowedListView solves the memory hungry issue for a long list?


Reply to this email directly or view it on GitHub.

@Kureev

This comment has been minimized.

Show comment
Hide comment
@Kureev

Kureev Dec 25, 2015

Contributor

Oh, sounds amazing! 😻

Contributor

Kureev commented Dec 25, 2015

Oh, sounds amazing! 😻

@facebook-github-bot

This comment has been minimized.

Show comment
Hide comment
@facebook-github-bot

facebook-github-bot Dec 29, 2015

@sahrens updated the pull request.

@sahrens updated the pull request.

@deanmcpherson

This comment has been minimized.

Show comment
Hide comment
@deanmcpherson

deanmcpherson Jan 11, 2016

Contributor

Hey @sahrens, I'm working on updating an internal tab bar component, which I'm have transition speed issues with complex views on iPad (in particular unmount component speed of views containing multiple list views). Is Incremental a good fit for improving this kind of perf? WindowedListView sounds like it may help with multiple listviews as well.

Contributor

deanmcpherson commented Jan 11, 2016

Hey @sahrens, I'm working on updating an internal tab bar component, which I'm have transition speed issues with complex views on iPad (in particular unmount component speed of views containing multiple list views). Is Incremental a good fit for improving this kind of perf? WindowedListView sounds like it may help with multiple listviews as well.

@sahrens

This comment has been minimized.

Show comment
Hide comment
@sahrens

sahrens Jan 11, 2016

Contributor

Doubt it would help with unmount - any idea why that's slow?

This might help with transition smoothness, but doesn't help with total speed. It's goal is to improve responsiveness, so if you touch the screen during a big render, the app can respond immediately rather than waiting for that render to complete - would that help what you're seeing?

On Jan 10, 2016, at 9:09 PM, Dean McPherson notifications@github.com wrote:

Hey @sahrens, I'm working on updating an internal tab bar component, which I'm have transition speed issues with complex views on iPad (in particular unmount component speed of views containing multiple list views). Is Incremental a good fit for improving this kind of perf? WindowedListView sounds like it may help with multiple listviews as well.


Reply to this email directly or view it on GitHub.

Contributor

sahrens commented Jan 11, 2016

Doubt it would help with unmount - any idea why that's slow?

This might help with transition smoothness, but doesn't help with total speed. It's goal is to improve responsiveness, so if you touch the screen during a big render, the app can respond immediately rather than waiting for that render to complete - would that help what you're seeing?

On Jan 10, 2016, at 9:09 PM, Dean McPherson notifications@github.com wrote:

Hey @sahrens, I'm working on updating an internal tab bar component, which I'm have transition speed issues with complex views on iPad (in particular unmount component speed of views containing multiple list views). Is Incremental a good fit for improving this kind of perf? WindowedListView sounds like it may help with multiple listviews as well.


Reply to this email directly or view it on GitHub.

@facebook-github-bot

This comment has been minimized.

Show comment
Hide comment
@facebook-github-bot

facebook-github-bot Feb 12, 2016

@sahrens updated the pull request.

@sahrens updated the pull request.

@facebook-github-bot

This comment has been minimized.

Show comment
Hide comment
@facebook-github-bot

facebook-github-bot Feb 19, 2016

@sahrens updated the pull request.

@sahrens updated the pull request.

@bestander bestander closed this Mar 1, 2016

@bestander bestander deleted the sahrens-incremental-preview branch Mar 1, 2016

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