-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
Milestone
Comments
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.
This is starting to look less and less likely, other controls are starting to use the Dispatcher for measurement as well. |
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.
Bumping up the priority of this. It's very unclean the way we're currently doing text measurement. |
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.
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.
Fixed as of #542 |
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.
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
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.
The text was updated successfully, but these errors were encountered: