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

Enable ReactTextViewManager measurement off the dispatcher thread. #106

Closed
rozele opened this issue Jan 8, 2016 · 4 comments
Closed

Enable ReactTextViewManager measurement off the dispatcher thread. #106

rozele opened this issue Jan 8, 2016 · 4 comments
Assignees
Milestone

Comments

@rozele
Copy link
Collaborator

rozele commented Jan 8, 2016

Currently, the ReactTextViewManager (and the corresponding ReactTextShadowNode) measures the size of a TextBlock by instantiating one on the dispatcher thread and performing a measure operation. We should instead come up with a way to "simulate" the text measurement, to layout calculations on a background thread.

@rozele rozele self-assigned this Jan 8, 2016
@rozele rozele added this to the View Management milestone Jan 8, 2016
rozele added a commit that referenced this issue Jan 8, 2016
In order to leverage the CSSNode class to its fullest, various view managers need to override the measurement algorithm to determine the proper width and height needed for a view.

For now, we needed to move the measurement of FrameworkElements to the dispatcher thread, as WinRT does not have any text formatter or other hooks for determining the size of text without mimicking the element itself.  Issue #106 covers this.
@rozele
Copy link
Collaborator Author

rozele commented Jan 27, 2016

This is starting to look less and less likely, other controls are starting to use the Dispatcher for measurement as well.

@rozele rozele removed their assignment Feb 18, 2016
rozele added a commit that referenced this issue Feb 21, 2016
In order to leverage the CSSNode class to its fullest, various view managers need to override the measurement algorithm to determine the proper width and height needed for a view.

For now, we needed to move the measurement of FrameworkElements to the dispatcher thread, as WinRT does not have any text formatter or other hooks for determining the size of text without mimicking the element itself.  Issue #106 covers this.
rozele added a commit that referenced this issue Mar 1, 2016
In order to leverage the CSSNode class to its fullest, various view managers need to override the measurement algorithm to determine the proper width and height needed for a view.

For now, we needed to move the measurement of FrameworkElements to the dispatcher thread, as WinRT does not have any text formatter or other hooks for determining the size of text without mimicking the element itself.  Issue #106 covers this.
@rozele
Copy link
Collaborator Author

rozele commented Mar 11, 2016

Bumping up the priority of this. It's very unclean the way we're currently doing text measurement.

@rozele rozele added p2 and removed nice-to-have p3 labels Mar 11, 2016
@rozele rozele removed the ready label Mar 18, 2016
rozele added a commit that referenced this issue Apr 21, 2016
In order to leverage the CSSNode class to its fullest, various view managers need to override the measurement algorithm to determine the proper width and height needed for a view.

For now, we needed to move the measurement of FrameworkElements to the dispatcher thread, as WinRT does not have any text formatter or other hooks for determining the size of text without mimicking the element itself.  Issue #106 covers this.
@ebragge ebragge assigned ebragge and unassigned ebragge Apr 27, 2016
@rozele rozele added the ready label Apr 29, 2016
rozele added a commit that referenced this issue May 17, 2016
In order to leverage the CSSNode class to its fullest, various view managers need to override the measurement algorithm to determine the proper width and height needed for a view.

For now, we needed to move the measurement of FrameworkElements to the dispatcher thread, as WinRT does not have any text formatter or other hooks for determining the size of text without mimicking the element itself.  Issue #106 covers this.
rozele added a commit that referenced this issue May 18, 2016
In order to leverage the CSSNode class to its fullest, various view managers need to override the measurement algorithm to determine the proper width and height needed for a view.

For now, we needed to move the measurement of FrameworkElements to the dispatcher thread, as WinRT does not have any text formatter or other hooks for determining the size of text without mimicking the element itself.  Issue #106 covers this.
rozele added a commit that referenced this issue May 25, 2016
In order to leverage the CSSNode class to its fullest, various view managers need to override the measurement algorithm to determine the proper width and height needed for a view.

For now, we needed to move the measurement of FrameworkElements to the dispatcher thread, as WinRT does not have any text formatter or other hooks for determining the size of text without mimicking the element itself.  Issue #106 covers this.
@rozele rozele self-assigned this Aug 16, 2016
@rozele
Copy link
Collaborator Author

rozele commented Aug 16, 2016

Fixed as of #542

@rozele rozele closed this as completed Aug 16, 2016
@rozele rozele removed the ready label Aug 16, 2016
GantMan pushed a commit to infinitered/react-native-windows that referenced this issue Sep 29, 2016
In order to leverage the CSSNode class to its fullest, various view managers need to override the measurement algorithm to determine the proper width and height needed for a view.

For now, we needed to move the measurement of FrameworkElements to the dispatcher thread, as WinRT does not have any text formatter or other hooks for determining the size of text without mimicking the element itself.  Issue microsoft#106 covers this.
@rozele rozele reopened this Nov 21, 2016
@rozele
Copy link
Collaborator Author

rozele commented Jun 29, 2017

The fix above was reverted here a3a2f30

rozele added a commit that referenced this issue Jul 27, 2017
Prior to this change, layout was performed on any background thread. Because of this, we had to perform text measurement on the UI thread, which incurred many blocking calls to the UI. This change adds a secondary CoreApplicationView + Dispatcher in UWP and a secondary STA thread in WPF. This thread is characterized as the layout thread, which is only used from the UIManager. All text measurement calls can now be made directly without having to context switch to the main UI thread.

Fixes #106
rozele pushed a commit that referenced this issue Jun 21, 2019
Build complete and integrated with Travis
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants