macos: Set layerContentsPlacement to topleft #3731
Conversation
|
One weird thing I noticed, that when dragging a window between hidpi and lodpi screens, it tries to animate the change in scale, which I find weird. And I'm not sure how to disable, as I don't know around what I could do the CATransation. But it is a really minor thing. |
src/backend/metal/src/lib.rs
Outdated
| @@ -338,7 +338,17 @@ impl GfxManagedMetalLayerDelegate { | |||
| } | |||
| decl.register(); | |||
| }); | |||
| GfxManagedMetalLayerDelegate(Class::get(CAML_DELEGATE_CLASS).unwrap()) | |||
| let klass = Class::get(CAML_DELEGATE_CLASS).unwrap(); | |||
| let obj = unsafe { msg_send![klass, new] }; | |||
src/backend/metal/src/lib.rs
Outdated
| fn drop(&mut self) { | ||
| unsafe { | ||
| let () = msg_send![self.0, release]; | ||
| }; |
src/backend/metal/src/lib.rs
Outdated
| // doesn't result in stretching, which combined with newly rendered | ||
| // frames results in jerky movement. | ||
| #[allow(non_upper_case_globals)] | ||
| const NSViewLayerContentsPlacementTopLeft: i32 = 11; |
There was a problem hiding this comment.
I'm a bit concerned about this path. The view is something controlled by the client, not us. We should try to do minimum changes, if any, to that view. Is it reasonable to say that this should be a winit problem? Or basically, whoever actually manages the NSView, while gfx-rs shouldn't be that person.
There was a problem hiding this comment.
now, I agree that winit should be setting the placement, but last time I tried, it didn't work, so I figured it is something about the layer within the view, and not the view itself.
I can do more tests with winit setting it too, but it'll take some time until I can get to it
There was a problem hiding this comment.
thanks! if there is something we are missing here, we'd need to know, what it is.
Note that this issue doesn't need to block gfx-0.8, since it's not an API breaking fix.
|
How about this? Though I was thinking of making the layer delegate a proper instance anyway, with the idea that it would actually return NO, but set the contentScale directly itself and then call out for the layer/view |
By setting the contentGravity to top-left, the resizing of the window doesn't result in stretching, which combined with newly rendered frames results in jerky movement.
The delegate was set to the class of an object but the delegate method was an instance method. This just makes it a class method, thereby fixing the `layer:shouldInheritContentsScale:fromWindow:` method.
No description provided.