It's not that visible on the gif, you can only see it when going back from Irene.

When going from UsersListScreen to UserDetailsScreen everything works fine. The sequence is as follows:

1. startElement from previous screen is gone
2. endElement calls onElementRegistered and hides itself (by using alpha = 0)
3. transition is set to SharedElementTransition.WaitingForEndElementPosition and invalidateTransitionsOverlay() is called.
4. SharedElementTransitionsOverlay reads that transition and draws SharedElementTransitionPlaceholder of startElement for a brief moment until endElement will be positioned and we can launch the real transition.
5. endElement calls onElementPositioned.
6. transition is set to SharedElementTransition.InProgress and invalidateTransitionsOverlay() is called.
7. SharedElementTransitionsOverlay reads and draws the real transition from startElement to endElement

Steps 2, 3 and 4 are done in the same pass (frame?). endElement hides itself, but at the same time we already have a placeholder of startElement drawn by SharedElementTransitionsOverlay.

When going from UserDetailsScreen to UsersListScreen there is one difference though. It looks like AdapterList (that is used on UsersListScreen) never disposes its list items, even when it's gone (#1, https://issuetracker.google.com/issues/150174792). I believe it causes it to be positioned "instantly"(?). The sequence is as follows:

1. startElement from previous screen is gone
2. endElement calls onElementRegistered and hides itself (by using alpha = 0)
3. transition is set to SharedElementTransition.WaitingForEndElementPosition and invalidateTransitionsOverlay() is called.
4. DIFFERENT: NOT HAPPENING
5. DIFFERENT: endElement calls onElementPositioned in the same pass as 2 and 3. SharedElementTransitionsOverlay had no chance to refresh, so we have missed frame.
6. transition is set to SharedElementTransition.InProgress and invalidateTransitionsOverlay() is called.
7. SharedElementTransitionsOverlay reads and draws the real transition from startElement to endElement

The types names may be a bit misleading, because they can be used interchangeably. It doesn't matter if first one if FROM or TO. They are only used to detect the "other" one from the pair.

Without it I have no idea how to detect that one element was on "previous" screen and second one is on "next" screen, because there is no concept of screens and transitions between them. We cannot rely on things like position or hierarchy change. Not every hierarchy change is a "screen" change and that would make it transition from its old position to its new position (or old/new places in hierarchy).

Maybe a better idea would be to change it to something more generic like screen: String so one can specify values like:

• "list" on one screen
• "details" on second screen

For now I stayed with FROM and TO because it makes it super simple to choose one o two enum values.

Causes issues in the following scenario:

1. On first screen there is an AdapterList component with FROM element.
2. User navigates to next screen, that has no SharedElement.
3. User navigates to next screen that has a TO element.

Here the transition between FROM and TO would start because we still remember that FROM element from first screen. This is due to a bug in Compose that cause AdapterList to never invoke onDispose on list items, so FROM element would never know it disappeared.

https://issuetracker.google.com/issues/150174792 I'm not sure if any workaround can be implemented before it's fixed.