Potential fix for #2422 (#4197)

Conrad Irwin created

- it seems like layer.drawable_size() is 0,0 in metal_renderer.rs:189 
- we set this in two places:
    - in response to a CALayerDelegate setFrameSize: event
- in response to a CALayerDelegate viewDidChangeBackingProperties:
event.
- it looks like if we don't set it in either of these cases we get a
different failure mode: the view is zoomed just wrong.
- That said, I can reproduce the screenshot if .scale_factor() returns
0.
- This might happen if [nativeWindow screen] is nil, which happens when
the window is off screen.
    - possible that zed started with offscreen window?
- I would expect that viewDidChangeBackingProperties would fire when
that changed.
    - potential fix: default to 2.0

Release Notes:

- Fixed Zed occasionally rendering blank on laungh
([#2422](https://github.com/zed-industries/community/issues/2422)).

Change summary

crates/gpui/src/platform/mac/window.rs | 14 +++++++++++++-
1 file changed, 13 insertions(+), 1 deletion(-)

Detailed changes

crates/gpui/src/platform/mac/window.rs 🔗

@@ -1003,9 +1003,21 @@ impl PlatformWindow for MacWindow {
 }
 
 fn get_scale_factor(native_window: id) -> f32 {
-    unsafe {
+    let factor = unsafe {
         let screen: id = msg_send![native_window, screen];
         NSScreen::backingScaleFactor(screen) as f32
+    };
+
+    // We are not certain what triggers this, but it seems that sometimes
+    // this method would return 0 (https://github.com/zed-industries/community/issues/2422)
+    // It seems most likely that this would happen if the window has no screen
+    // (if it is off-screen), though we'd expect to see viewDidChangeBackingProperties before
+    // it was rendered for real.
+    // Regardless, attempt to avoid the issue here.
+    if factor == 0.0 {
+        2.
+    } else {
+        factor
     }
 }