Revisit workaround for window resizing events overloading the shadow queue #459
Comments
ghost
added
the
|
cc @tom-un |
4 tasks
|
This issue is stale because it has been open 365 days with no activity. Remove stale label or comment or this will be closed in 7 days. |
|
I would like to keep this open. |
christophpurrer
pushed a commit
to christophpurrer/react-native-macos
that referenced
this issue
Aug 2, 2022
…crosoft#439)" This change reverts microsoft#459 - but still tries to address the original issues: - microsoft#422 - microsoft#322 This also addresses an issue when programmatically resizing windows where the RCTRootContentView may end up at the wrong size because an in-flight layout gets resolved after the resize on the main thread. We now keep sync dispatch on the shadow queue for live resizing windows (to prevent tearing) but also dispatch async (as done on iOS) so the latest new size is sure to win. The block has a check to bail if the size doesn't change, so this isn't a perf drain running the block twice.
4 tasks
christophpurrer
pushed a commit
to christophpurrer/react-native-macos
that referenced
this issue
Aug 2, 2022
…crosoft#439)" This change reverts microsoft#459 - but still tries to address the original issues: - microsoft#422 - microsoft#322 This also addresses an issue when programmatically resizing windows where the RCTRootContentView may end up at the wrong size because an in-flight layout gets resolved after the resize on the main thread. We now keep sync dispatch on the shadow queue for live resizing windows (to prevent tearing) but also dispatch async (as done on iOS) so the latest new size is sure to win. The block has a check to bail if the size doesn't change, so this isn't a perf drain running the block twice.
christophpurrer
added a commit
to christophpurrer/react-native-macos
that referenced
this issue
Aug 4, 2022
…crosoft#439)" (microsoft#1318) This change reverts microsoft#459 - but still tries to address the original issues: - microsoft#422 - microsoft#322 This also addresses an issue when programmatically resizing windows where the RCTRootContentView may end up at the wrong size because an in-flight layout gets resolved after the resize on the main thread. We now keep sync dispatch on the shadow queue for live resizing windows (to prevent tearing) but also dispatch async (as done on iOS) so the latest new size is sure to win. The block has a check to bail if the size doesn't change, so this isn't a perf drain running the block twice. Co-authored-by: Scott Kyle <[email protected]>
|
Can this one be closed now since #1318 landed? |
shwanton
pushed a commit
to shwanton/react-native-macos
that referenced
this issue
Feb 13, 2023
…crosoft#439)" (microsoft#1318) This change reverts microsoft#459 - but still tries to address the original issues: - microsoft#422 - microsoft#322 This also addresses an issue when programmatically resizing windows where the RCTRootContentView may end up at the wrong size because an in-flight layout gets resolved after the resize on the main thread. We now keep sync dispatch on the shadow queue for live resizing windows (to prevent tearing) but also dispatch async (as done on iOS) so the latest new size is sure to win. The block has a check to bail if the size doesn't change, so this isn't a perf drain running the block twice. Co-authored-by: Scott Kyle <[email protected]>
shwanton
pushed a commit
to shwanton/react-native-macos
that referenced
this issue
Mar 10, 2023
…crosoft#439)" (microsoft#1318) This change reverts microsoft#459 - but still tries to address the original issues: - microsoft#422 - microsoft#322 This also addresses an issue when programmatically resizing windows where the RCTRootContentView may end up at the wrong size because an in-flight layout gets resolved after the resize on the main thread. We now keep sync dispatch on the shadow queue for live resizing windows (to prevent tearing) but also dispatch async (as done on iOS) so the latest new size is sure to win. The block has a check to bail if the size doesn't change, so this isn't a perf drain running the block twice. Co-authored-by: Scott Kyle <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
In order to fix #322 and #422, we've added throttling of layout events (#439) to reduce load on the shadow queue. Post-Fabric, we should revisit this workaround and see if we can implement a proper fix.
The text was updated successfully, but these errors were encountered: